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

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.
That you call this a guess seems disingenuous at least and dishonest
at most. it is as if you are denying mathematical induction.

By your defintions, the ONLY correct simulation of D by H MUST follow the call H into the instructions of H, and then continue there forever until H either gives up simulating, or it happens to simulate the return from H to D (which doesn't look like it will ever happen).
 

Yes and when I say 2 + 3 = 5 you are not free to disagree and be
correct.

This is the ONLY thing that matches your definition of Correct Simulation.
 

The x86 language defines the semantics of correct simulation that
you denigrate this to my opinion seems disingenuous at least and
dishonest at most.

And that means that you definition of the "Input" is shown to be incorrect (or insufficient for H to do what it needs to do). The input CAN NOT be just those instructions shown below, but must include the contents of ALL the memory used by the program.
 

It is the sequence of x86 instructions specified by the machine
language of D that is being examined. We cannot simply ignore
the recursive simulation effect of the call from D to H(D,D).
That D makes this call is what make D correctly simulated by H
fail to halt.

And this comes out naturally, because to ask about the program represented by the input, the input needs to represent a FULL PROGRAM, which includes ALL of the algorithm used by the code, so ALL of the program.
 

That D calls H in recursive simulation is what makes D correctly
simulated by H never halt. H is merely watching what D does
until it see that D correctly simulated by H cannot possibly halt
on the basis of something just like mathematical induction.
We can directly see that 1,2,3...N recursive simulations do
not result in D correctly simulated by H reaching its simulated
final state of [00000d1d].

Thus, the input "D", includes its copy of H that was DEFINED by Linz and Sipser to be part of the machine, and when you do your logic, you can't change that code.
 

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
When embedded_H is a UTM we can see that Ĥ ⟨Ĥ⟩ never halts.
This by itself proves that the same thing applies when embedded_H
is based on a UTM that stops simulating and rejects its input at
any point after it sees
two complete simulations show a pair of identical TMD's are
simulating a pair of identical inputs.  We can see this thus
proving recursive simulation.

If this means that you can't do your imagining of different Hs, then you can't do that operation.
 Any H you imagine being given the same input as this H, must see the code for that original H, not the new hypothetical H you are imagining.
 Which sort of blows you your whole argument.
 

>
_D()
[00000cfc](01) 55          push ebp
[00000cfd](02) 8bec        mov ebp,esp
[00000cff](03) 8b4508      mov eax,[ebp+08]
[00000d02](01) 50          push eax       ; push D
[00000d03](03) 8b4d08      mov ecx,[ebp+08]
[00000d06](01) 51          push ecx       ; push D
[00000d07](05) e800feffff  call 00000b0c  ; call H
[00000d0c](03) 83c408      add esp,+08
[00000d0f](02) 85c0        test eax,eax
[00000d11](02) 7404        jz 00000d17
[00000d13](02) 33c0        xor eax,eax
[00000d15](02) eb05        jmp 00000d1c
[00000d17](05) b801000000  mov eax,00000001
[00000d1c](01) 5d          pop ebp
[00000d1d](01) c3          ret
Size in bytes:(0034) [00000d1d]
>

 

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer