Re: D(D) simulated by H cannot possibly reach past its own line 03

On 6/3/2024 9:17 AM, Mikko wrote:

On 2024-06-03 12:25:48 +0000, olcott said:
>

On 6/3/2024 2:39 AM, Mikko wrote:

On 2024-06-02 14:50:26 +0000, olcott said:
>

On 6/2/2024 4:50 AM, Fred. Zwarts wrote:

Op 03.mei.2024 om 15:40 schreef olcott:

00 int H(ptr x, ptr x)  // ptr is pointer to int function
01 int D(ptr x)
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11   H(D,D);
12 }
>
We are examining the behavior of D(D) for every possible H/D pair
where 1 to N steps of D(D) are simulated by H.
>
*Execution Trace*
Line 11: main() invokes H(D,D) that simulates D(D)
>
*keeps repeating* (unless aborted)
Line 01
Line 02
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.

>
The Linz proof is based on the pathological relation ship that D contradicts the result of H. This is expressed in lines 04, 05, 06 of D, above.
It is strange that olcott claims that the simulation never sees the pathological part of D. He now seems to shift the meaning of pathological to the mere fact that D calls H. Lines 04, 05, and 06 are completely irrelevant.
In fact, any function that calls H now become pathological.
>
E.G. if we replace D with a function P that only returns its own Halt_Status:
>
01 int P(ptr x)
02 {
03   int Halt_Status = H(x, x);
04
05
06   return Halt_Status;
07 }
>
Then we would normally expect that, because H is required to halt, P would halt as well. But the simulation of P by H does not halt. So, P, when it halts, reports that it not halting.
>
The problem here is, that H is unable to simulate itself to its final state. That has no relation with the Linz proof, it is a problem of H.
>
So, there is another *Simulation invariant*
H correctly simulated by H cannot possibly reach its own return.
>

>
Already addressed in another reply.

>
Which reply? The one where you said you made a mistake? Or typo?
>

>
I am not going to answer the same question from multiple people.

>
Your choice. But you can't keep multiple people from seeing your
lack of answer.
>

 This is my canned reply that no one has attempted to refute because
they know it is irrefutable. When we are analyzing x86 code and
someone disagrees that is like disagreeing that 2 + 3 = 5.
 That is why it is essential that I get agreement on the x86/C
code before moving on to Turing Machines. If they are going to
lie about arithmetic we cannot trust them with more complex math.
 DD correctly emulated by any HH that can possibly exist DOES NOT HALT
DD correctly emulated by any HH that can possibly exist DOES NOT HALT
DD correctly emulated by any HH that can possibly exist DOES NOT HALT

 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]