Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES

On 2024-06-17 12:57:00 +0000, olcott said:

On 6/17/2024 2:19 AM, Mikko wrote:

On 2024-06-16 12:48:56 +0000, olcott said:
 

On 6/16/2024 3:00 AM, Mikko wrote:

On 2024-06-16 01:42:29 +0000, olcott said:
 

On 6/15/2024 8:19 PM, Richard Damon wrote:

On 6/15/24 8:48 PM, olcott wrote:

On 6/15/2024 7:13 PM, Richard Damon wrote:

On 6/15/24 8:05 PM, olcott wrote:

On 6/15/2024 6:37 PM, Richard Damon wrote:

On 6/15/24 7:30 PM, olcott wrote:

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

On 6/13/2024 8:24 PM, Richard Damon wrote:
 > On 6/13/24 11:32 AM, olcott wrote:
 >>
 >> It is contingent upon you to show the exact steps of how H computes
 >> the mapping from the x86 machine language finite string input to
 >> H(D,D) using the finite string transformation rules specified by
 >> the semantics of the x86 programming language that reaches the
 >> behavior of the directly executed D(D)
 >>
 >
 > Why? I don't claim it can.
 The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.
 After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

 Nope, the steps of D correctly simulated by H will EXACTLY match the steps of D directly executed, until H just gives up and guesses.
 

 When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N
recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

 Nope. Because an aborted simulation doesn't say anything about Halting,
 

 It is the mathematical induction that says this.
 

WHAT "Mathematical Induction"?
 

 A proof by induction consists of two cases. The first, the base
case, proves the statement for n = 0 without assuming any knowledge
of other cases. The second case, the induction step, proves that
if the statement holds for any given case n = k then it must also
hold for the next case n = k + 1 These two steps establish that the
statement holds for every natural number n.
https://en.wikipedia.org/wiki/Mathematical_induction

 Ok, so you can parrot to words.
 

 It is true that after one recursive simulation of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

 Which means you consider that D has been bound to that first H, so you have instruciton to simulate in the call H.
 

 *We directly see this is true for every N thus no assumption needed*
It is true that after N recursive simulations of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

 Nope, because to do the first step, you had to bind the definition of the first H to D, and thus can not change it.

 So infinite sets are permanently beyond your grasp.
The above D simulated by any H has the same property
of never reaching its own simulated machine address
at [00000d1d].
 What I mistook for dishonestly is simply a lack
of comprehension.
 

  But it isn't an infinite set.
 

 Sure it is you are just clueless.
I mistook your ignorance for deception.
 

We don't ask an infinite set a question, or give a decider an infinite set of inputs.
 

 Yes we do and this is simply over your head.
 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 The second ⊢* wildcard specifies this infinite set.

 As you should already know, ⊢* as used by Linz is not a wildcard.
It is a repeated application of ⊢ without showing intermediate steps.
 

 It *is* a wild card such that the Linz template simultaneously
specifies an infinite set of machines.

 No, it is not. In Linz' book an expression containing ⊢* (or just ⊢) does
not specify anything. It merely expresses something about a computation.
 

 No you are wrong.
 The Linz term “move” means a state transition and its corresponding
tape head action {move_left, move_right, read, write}.
⊢* indicates an arbitrary number of moves.

Which is not what the word "wildcard" means. And It means the sequence of
moves that connects the configration on its left side to the configration
on its right side. There is usually only one such sequence so not very
"arbitrary".
--
Mikko