Re: Can you see that D correctly simulated by H remains stuck in recursive simulation?

On 5/24/24 5:03 AM, Mikko wrote:

On 2024-05-23 17:04:49 +0000, olcott said:
 

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }
>
The above template refers to an infinite set of H/D pairs where D is
correctly simulated by pure function H. This was done because many
reviewers used the shell game ploy to endlessly switch which H/D pair
was being referred to.
>
*Correct Simulation Defined*
    This is provided because every reviewer had a different notion of
    correct simulation that diverges from this notion.
>
    A simulator is an x86 emulator that correctly emulates at least one
    of the x86 instructions of D in the order specified by the x86
    instructions of D.
>
    This may include correctly emulating the x86 instructions of H in
    the order specified by the x86 instructions of H thus calling H(D,D)
    in recursive simulation.
>
*Execution Trace*
    Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 03
    of D. This invokes H(D,D) again to repeat the process in endless
    recursive simulation.

 One can see that D is never stuch in recursive simulation unless H is.
Whether H is cannot be seen has the details of H are not shown. Even
if they were H must, in order to simulate any x86 execution, be so
big and complicated that essential aspect may be hard to see; depending,
of course, on how the code is organized.
 

Yep, that is a key part of the issue.
We could say that his H proves that his H isn't a decider, because it isn't a "Halting Program" for the input.