Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD

Op 03.jun.2024 om 05:20 schreef olcott:

On 6/2/2024 10:13 PM, Richard Damon wrote:

On 6/2/24 10:54 PM, olcott wrote:

IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE INPUT SPECIFIES.
That you did get confused by the Linz text proves that you do
get confused. Previously it looked just like willful deception.

>
Which is, for a Halt Decider, exactly and only the behavior of the Turing Machine the input describes.
>
PERIOD.
>
Anything else is just a LIE.
>

>

You don't seem to understand that you can't just "redefine" the system to meet your desires.
>

>
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.

>
No, Running DD(DD) and seeing that it will never, after an unbounded number of steps, indicate it is non-halting.
>
DEFINITION.
>

>
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.

>
Right, and the input is a representation of a Turing Machine and its input, whose behavior the decider is to decide on.
>

>
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.
>

>
And that is the machine the input describes.
>
ANYTHING ELSE IS JUST A LIE.
>

You can't get away with implicitly saying that you
just don't "believe in" UTMs.

>
I do, and a UTM is DEFINED as a machine that exactly reproduces the behavior of the machine described by its input.
>

 *If that was true then you prove that this statement is false*
*We can see that the following DD cannot possibly halt when*
*correctly simulated by every HH that can possibly exist*
 typedef int (*ptr)();  // ptr is pointer to int function in C
00       int HH(ptr p, ptr i);
01       int DD(ptr p)
02       {
03         int Halt_Status = HH(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
 _DD()
[00001c22] 55         push ebp
[00001c23] 8bec       mov ebp,esp
[00001c25] 51         push ecx
[00001c26] 8b4508     mov eax,[ebp+08]
[00001c29] 50         push eax        ; push DD 1c22
[00001c2a] 8b4d08     mov ecx,[ebp+08]
[00001c2d] 51         push ecx        ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342   ; call HH
[00001c33] 83c408     add esp,+08
[00001c36] 8945fc     mov [ebp-04],eax
[00001c39] 837dfc00   cmp dword [ebp-04],+00
[00001c3d] 7402       jz 00001c41
[00001c3f] ebfe       jmp 00001c3f
[00001c41] 8b45fc     mov eax,[ebp-04]
[00001c44] 8be5       mov esp,ebp
[00001c46] 5d         pop ebp
[00001c47] c3         ret
Size in bytes:(0038) [00001c47]
 

It is clear (both from the C code as from the compiled code) that at the moment that the outer simulator reaches the place where DD calls HH then HH finds *itself* in a 'repeated state'. At that same moment DD is *not* (yet) in a repeated state. (DD may get in a repeated state if the called HH would start a new simulation.) So, the only conclusion is that it is HH that displays repetition. And because of that DD will repeat as well.
By using simulation, a new halting problem is introduced, that has nothing to do with the pathological part of DD n lines 04, 05 and 06. This pathological part is not even processed by the simulation.