• Re: Can you see that D correctly simulated by H remains stuck in recurs

    From Marcel Mueller@21:1/5 to All on Thu May 23 19:09:35 2024
    XPost: comp.lang.c++

    Am 23.05.24 um 18:52 schrieb olcott:
    typedef int (*ptr)();  // ptr is pointer to int function in C
    [...]

    Groundhog Day!

    :-D


    Marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam@21:1/5 to olcott on Thu May 23 17:52:52 2024
    XPost: comp.lang.c++

    olcott writes:

    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 }

    Anyone who writes something like this, in my day job, will get fired before
    the end of the day.

    This is the worst chunk of code I've seen in at least fifteen years. It
    shows a complete lack of understanding of fundamental principles of C and
    C++.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam@21:1/5 to Chris M. Thomasson on Thu May 23 21:12:11 2024
    XPost: comp.lang.c++

    Chris M. Thomasson writes:

    On 5/23/2024 12:25 PM, olcott wrote:
    On 5/23/2024 2:22 PM, Bonita Montero wrote:
    [...]
    You're really insane.


    You might guess that by making sure to ignore
    what I said. I am now offering a cash reward
    of $10.


    lol!

    Not to mention that's it's barely enough to pay for a cup of Starbucks
    coffee. Not to mention that I prefer a McCafe anyway. Maybe for that, and a breakfast burrito, I might be motivated to look into this further.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam@21:1/5 to olcott on Thu May 23 21:10:08 2024
    XPost: comp.lang.c++

    olcott writes:


    This is the worst chunk of code I've seen in at least fifteen years. It
    shows a complete lack of understanding of fundamental principles of C and
    C++.


    It is the computer science of the Peter Linz halting
    problem proof translated into C. This too is a template:

    It's completely wrong. It suffers from a fundamental flaw of using an
    inverse logical loop that makes its boolean logic produce an irrational identity matrix.

    The shown code is worthless. It'll never work. Try again, from step 1. Start with the K&R book, beginning with Chapter 1.

    Can we please get back to the C or do you really want
    to stay off topic?

    As I already explained, it's syntactically invalid C, that no self-
    respecting C compiler will accept as well-formed code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam@21:1/5 to olcott on Fri May 24 07:42:42 2024
    XPost: comp.lang.c++

    olcott writes:


    As I already explained, it's syntactically invalid C, that no self-
    respecting C compiler will accept as well-formed code.


    Fibber !

    On 5/20/2024 9:23 PM, Keith Thompson wrote:
    The code as presented is a valid C *translation unit*, but it is
    not a valid *program*, and it has no behavior.


    Please stop accusing Mr. Thompson. He's only telling you the truth: the
    shown code "is not a valid *program*". Which part of that you did not understand? If you don't believe me, just ask Keith Thompson.

    That should be the last word on this: your code is not a valid program.
    Thank you for playing. You can go home now.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Harnden@21:1/5 to olcott on Fri May 24 13:10:52 2024
    XPost: comp.lang.c++

    On 23/05/2024 17:52, olcott wrote:
    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 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.

    In the above case 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.


    So, you have: main -> H -> D -> H -> D -> ... -> H -> D until you run
    out of stack?

    No return statement is ever reached.
    Line 3 never completes.
    Halt_Status at line 3 never gets a value.

    </shrug>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to olcott on Fri May 24 15:37:29 2024
    XPost: comp.lang.c++

    On 24/05/2024 15:08, olcott wrote:
    On 5/24/2024 7:10 AM, Richard Harnden wrote:
    On 23/05/2024 17:52, olcott wrote:
    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 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.

    In the above case 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.


    So, you have: main -> H -> D -> H -> D -> ... -> H -> D until you run
    out of stack?

    No return statement is ever reached.
    Line 3 never completes.
    Halt_Status at line 3 never gets a value.

    </shrug>


    Thanks.

    Proving that D correctly simulated by H never reaches its final
    state at line 06 and halts.

    No, it does not.

    As Richard says, you have main -> H -> D -> H -> ...

    For any finite system, you will run out of stack space. This is
    undefined behaviour in C. /Anything/ can happen - including halting,
    returning a halt status of 1, or a halt status of 0, or a not halting,
    or printing out the works of Shakespeare. Or it could cause the program
    to jump directly to line 6. Once you hit undefined behaviour, you
    cannot prove /anything/.

    Thus proving that the halting problem's
    counter-example input D would be correctly determined to be non-halting
    by its simulating termination analyzer H.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to All on Fri May 24 13:57:40 2024
    XPost: comp.lang.c++

    In article <[email protected]>,
    Sam <[email protected]> kissed the ring thusly:
    ...
    Please stop accusing Mr. Thompson. He's only telling you the truth: the
    shown code "is not a valid *program*". Which part of that you did not >understand? If you don't believe me, just ask Keith Thompson.

    ...

    That should be the last word on this: your code is not a valid program.
    Thank you for playing. You can go home now.

    I'm sure Keith will show his love for you.

    --
    So to cure the problem of arrogant incompetent rich people we should turn
    the government over to an arrogant incompetent trust fund billionaire
    who knows nothing about government and who has never held a job in his
    entire spoiled life?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Fri May 24 16:05:36 2024
    XPost: comp.lang.c++

    Op 24.mei.2024 om 15:08 schreef olcott:
    On 5/24/2024 7:10 AM, Richard Harnden wrote:
    On 23/05/2024 17:52, olcott wrote:
    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 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.

    In the above case 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.


    So, you have: main -> H -> D -> H -> D -> ... -> H -> D until you run
    out of stack?

    No return statement is ever reached.
    Line 3 never completes.
    Halt_Status at line 3 never gets a value.

    </shrug>


    Thanks.

    Proving that D correctly simulated by H never reaches its final
    state at line 06 and halts. Thus proving that the halting problem's counter-example input D would be correctly determined to be non-halting
    by its simulating termination analyzer H.


    No. If true, it proves that no simulation is able to correctly determine
    the halting status of D, because simulations are not even able to
    simulate one line of D.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Fri May 24 16:28:01 2024
    XPost: comp.lang.c++

    Op 24.mei.2024 om 15:08 schreef olcott:
    On 5/24/2024 7:10 AM, Richard Harnden wrote:
    On 23/05/2024 17:52, olcott wrote:
    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 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.

    In the above case 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.


    So, you have: main -> H -> D -> H -> D -> ... -> H -> D until you run
    out of stack?

    No return statement is ever reached.
    Line 3 never completes.
    Halt_Status at line 3 never gets a value.

    </shrug>


    Thanks.

    Proving that D correctly simulated by H never reaches its final
    state at line 06 and halts. Thus proving that the halting problem's counter-example input D would be correctly determined to be non-halting
    by its simulating termination analyzer H.


    Since the claim is that the simulator never reaches line 04, the
    conclusion is that line 04, 05 and 06 do not play a role in the proof.
    Which means that we can delete them and still use the 'proof'. Then the
    'proof' is that any function that calls H would be non-halting, because
    H does not halt. That D does the opposite of what H returns is not used
    in the 'proof', because it is not part of the simulation.
    So, it would be equally correct to say that D1 does not halt, because H
    will never return from the recursive simulation:

    int H(ptr p, ptr i);
    int D1(ptr p)
    {
    return H(p, p);
    }
    int main()
    {
    H(D1,D1);
    return 0;
    }

    Of course that does not prove it. It only proves that simulation cannot
    be used in this way to determine the halting status.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Fri May 24 17:01:46 2024
    XPost: comp.lang.c++

    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.

    The case can be simplified even more (D is not needed):

    typedef int (*ptr)(); // ptr is pointer to int function in C
    00 int H(ptr p, ptr i);
    01 int main()
    02 {
    03 H(H,H);
    04 return 0;
    05 }

    If olcott's claim is true, then also main will never reach line 04. This
    would prove that H is non-halting. This would prove that a simulating halt-decider cannot be used as a halt-decider, because it does not halt.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam@21:1/5 to olcott on Fri May 24 13:27:06 2024
    XPost: comp.lang.c++

    olcott writes:

    On 5/23/2024 8:10 PM, Sam wrote:
    olcott writes:


    This is the worst chunk of code I've seen in at least fifteen years. It >>>> shows a complete lack of understanding of fundamental principles of C and >>>> C++.


    It is the computer science of the Peter Linz halting
    problem proof translated into C. This too is a template:

    It's completely wrong. It suffers from a fundamental flaw of using an
    inverse logical loop that makes its boolean logic produce an irrational
    identity matrix.

    The shown code is worthless. It'll never work. Try again, from step 1. Start >> with the K&R book, beginning with Chapter 1.

    Can we please get back to the C or do you really want
    to stay off topic?

    As I already explained, it's syntactically invalid C, that no

    It is not syntactically invalid C, why lie about this?

    Of course it is syntactically-invalid. No self-respecting C or C++ compiler will accept the shown code, cut/pasted exactly as shown. Line numbers have never been a part of either C or C++.

    When was the last time you successfully compiled C or C++ code?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Fri May 24 20:52:31 2024
    XPost: comp.lang.c++

    Op 24.mei.2024 om 18:57 schreef olcott:
    On 5/24/2024 10:01 AM, Fred. Zwarts wrote:
    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.

    The case can be simplified even more (D is not needed):


    We are ONLY asking about whether D correctly simulated by pure function
    H can possibly reach its own final state at line 06 and halt.

    Because H is a pure function we know that H halts. https://en.wikipedia.org/wiki/Pure_function#
    Every H of the above H/D pairs returns the meaningless value of 56.

    Maybe if you simplify your question, the answer is easier to find:
    The case can be simplified by eliminating the complexity of the template D:

    typedef int (*ptr)(); // ptr is pointer to int function in C
    00 int H(ptr p, ptr i);
    01 int main()
    02 {
    03 H(H,H);
    04 return 0;
    05 }

    Of the infinite set of H that simulate at least one step of its input,
    none of them, when simulated by H, halts, because none of them possibly
    reaches its final state.
    So, does H correctly recognize non-halting behaviour in H?

    D is an unneeded complexity, because the only property of D that is
    needed is that it calls H, so why not using H as input directly?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Sat May 25 09:32:45 2024
    XPost: comp.lang.c++

    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.


    Olcott's own words are that the simulation of D never reaches past line
    03. So the lines following line 03 do not play a role and, therefore,
    can be removed without changing the claim. This leads to:

    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 return H(p, p);
    04 }
    05
    06 int main()
    07 {
    08 H(D,D);
    09 return 0;
    10 }


    What we see is that the only property of D that is used is that it is a parameter duplicator. (Is that why it is called D?). H needs 2
    parameters, but it can be given only one input parameter, so the
    parameter duplicator is required to allow H to decide about itself.



    Of the infinite set of H that simulate at least one step, none of them,
    when simulated by H, halts, because none of them reaches its final
    state. Olcott's claim is equivalent to the claim of non-halting
    behaviour of H.
    This means that a simulating halt-decider is a bad idea, because the
    decider itself does not halt.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sat May 25 12:48:34 2024
    On 2024-05-24 13:08:52 +0000, olcott said:

    On 5/24/2024 7:10 AM, Richard Harnden wrote:
    On 23/05/2024 17:52, olcott wrote:
    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 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.

    In the above case 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.


    So, you have: main -> H -> D -> H -> D -> ... -> H -> D until you run
    out of stack?

    No return statement is ever reached.
    Line 3 never completes.
    Halt_Status at line 3 never gets a value.

    </shrug>


    Thanks.

    Proving that D correctly simulated by H never reaches its final
    state at line 06 and halts. Thus proving that the halting problem's counter-example input D would be correctly determined to be non-halting
    by its simulating termination analyzer H.

    Proving that the halting status of D is not determined by H.
    But this aspect is not C-specific: if H were written in Fortran
    it would do the same.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sat May 25 12:59:26 2024
    On 2024-05-24 16:57:36 +0000, olcott said:

    On 5/24/2024 10:01 AM, Fred. Zwarts wrote:
    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.

    The case can be simplified even more (D is not needed):


    We are ONLY asking about whether D correctly simulated by pure function
    H can possibly reach its own final state at line 06 and halt.

    Because H is a pure function we know that H halts.

    We don't know that H halts. The OP said the opposite:

    On 2024-05-23 16:52:21 +0000, olcott said:
    *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.

    To repeat in endless recursve simulation makes halting impossible.
    Apparently OP's interpretation of "pure function" does not imply
    halting.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to Fred. Zwarts on Sat May 25 13:03:13 2024
    On 2024-05-24 18:52:31 +0000, Fred. Zwarts said:

    Op 24.mei.2024 om 18:57 schreef olcott:
    On 5/24/2024 10:01 AM, Fred. Zwarts wrote:
    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.

    The case can be simplified even more (D is not needed):


    We are ONLY asking about whether D correctly simulated by pure function
    H can possibly reach its own final state at line 06 and halt.

    Because H is a pure function we know that H halts.
    https://en.wikipedia.org/wiki/Pure_function#
    Every H of the above H/D pairs returns the meaningless value of 56.

    Maybe if you simplify your question, the answer is easier to find:
    The case can be simplified by eliminating the complexity of the template D:

    typedef int (*ptr)(); // ptr is pointer to int function in C
    00 int H(ptr p, ptr i);
    01 int main()
    02 {
    03 H(H,H);
    04 return 0;
    05 }

    Of the infinite set of H that simulate at least one step of its input,
    none of them, when simulated by H, halts, because none of them possibly reaches its final state.
    So, does H correctly recognize non-halting behaviour in H?

    D is an unneeded complexity, because the only property of D that is
    needed is that it calls H, so why not using H as input directly?

    This has the problem that it is not clear what the corrct simulation
    of H(H) would be, considering that H requires two arguments. The purpose
    of D is to avoid that problem.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Fred. Zwarts on Sat May 25 16:48:01 2024
    XPost: comp.lang.c++

    On 25/05/2024 08:32, Fred. Zwarts wrote:
    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.


    Olcott's own words are that the simulation of D never reaches past line 03. So the lines following
    line 03 do not play a role and, therefore, can be removed without changing the claim. This leads to:

    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�������� return H(p, p);
    04������ }
    05
    06������ int main()
    07������ {
    08�������� H(D,D);
    09�������� return 0;
    10������ }


    Correct - as far as this specific thread is concerned. But PO's H and P are intended to be part of
    a larger argument supposedly refuting the standard halting problem (HP) proof (that no TM is a halt
    decider), e.g. as covered in the Linz book. PO has created an extract of that proof as a PDF that
    he sometimes links to.

    Also note that PO's claim (in this specific thread) is that the *simulation* of D never reaches past
    line 03. That is not saying that the *computation* D(D) never proceeds past line 3 or that D(D)
    never halts. (This is important in the wider HP proof context. PO is deeply confused on this point.)


    What we see is that the only property of D that is used is that it is a parameter duplicator. (Is
    that why it is called D?). H needs 2 parameters, but it can be given only one input parameter, so
    the parameter duplicator is required to allow H to decide about itself.

    Yes, but the rest of D is the key to its role in the HP proof - again, not relevant for this
    specific thread. [In HP proof, D's role is to calculate H's decision on whether D(D) halts and then
    behave in the opposite fashion, providing a counterexample to the claim that H correctly decides the
    halting behaviour of /all/ inputs (P,I). I.e. it shows that H gets it wrong for the case P=I=D.]




    Of the infinite set of H that simulate at least one step, none of them, when simulated by H, halts,
    because none of them reaches its final state. Olcott's claim is equivalent to the claim of
    non-halting behaviour of H.

    No - note my remarks above about the distinction between the behaviour of the *computation* D(D) and
    the (partial) *simulation* of that computation by H. H can simply choose to discontinue that
    simulation at any point [aka "abort" the simulation, in PO's terms], but then H would continue and
    halt.

    PO is pretty clueless about everything involved, and I believe he is quite incapable of abstract
    thought, including what people would generally regard as "logical reasoning", so there really is no
    point in arguing with him. (I mean Really...)

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sun May 26 11:05:47 2024
    On 2024-05-25 11:42:59 +0000, olcott said:

    On 5/25/2024 4:59 AM, Mikko wrote:
    On 2024-05-24 16:57:36 +0000, olcott said:

    On 5/24/2024 10:01 AM, Fred. Zwarts wrote:
    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.

    The case can be simplified even more (D is not needed):


    We are ONLY asking about whether D correctly simulated by pure function
    H can possibly reach its own final state at line 06 and halt.

    Because H is a pure function we know that H halts.

    We don't know that H halts. The OP said the opposite:


    The above references *pure function* H thus we do know
    that the spec *requires* H to halt. https://en.wikipedia.org/wiki/Pure_function

    In that case the spec requires halting, though OP was not clar about that.

    On 2024-05-23 16:52:21 +0000, olcott said:
    *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.

    Here OP is clear: H does not halt when both arguments are D.

    Therefore H does not conform to the spec.

    To repeat in endless recursve simulation makes halting impossible.
    Apparently OP's interpretation of "pure function" does not imply
    halting.


    Every H is required to halt and return a value.
    To make things simple every H returns the meaningless 56.
    It is endless recursive simulation until H halts.

    No, it isn't. "endless recursive simulation" means that H does not halt. Thereis no "unless" in the OP.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Sun May 26 13:01:59 2024
    XPost: comp.lang.c++

    Op 26.mei.2024 om 06:19 schreef olcott:
    On 5/25/2024 2:32 AM, Fred. Zwarts wrote:
    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.


    Olcott's own words are that the simulation of D never reaches past
    line 03. So the lines following line 03 do not play a role and,
    therefore, can be removed without changing the claim. This leads to:

    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         return H(p, p);
    04       }
    05
    06       int main()
    07       {
    08         H(D,D);
    09         return 0;
    10       }


    What we see is that the only property of D that is used is that it is
    a parameter duplicator. (Is that why it is called D?). H needs 2
    parameters, but it can be given only one input parameter, so the
    parameter duplicator is required to allow H to decide about itself.



    Of the infinite set of H that simulate at least one step, none of
    them, when simulated by H, halts, because none of them reaches its
    final state. Olcott's claim is equivalent to the claim of non-halting
    behaviour of H.
    This means that a simulating halt-decider is a bad idea, because the
    decider itself does not halt.

    Not at all.
       A simulator is an x86 emulator that correctly emulates 1 to N of the
       x86 instructions of D in the order specified by the x86 instructions
       of D. This may include M recursive emulations of H emulating itself
       emulating D.

       This means that D cannot possibly reach its own line 06 and halt
       in any finite steps of correct simulation. H is free to halt at
       any time after these N finite steps of correct simulation.



    D does not reach it own line 04 because the simulation of H does not
    return to D. So, it shows that the simulation of H does not reach it
    final state, which proves that H does not halt. A clear indication that
    a simulating decider is not a good idea, because it is required to halt,
    but H itself finds that H does not reach its final state.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Sun May 26 12:57:25 2024
    XPost: comp.lang.c++

    Op 25.mei.2024 om 13:22 schreef olcott:
    On 5/25/2024 2:32 AM, Fred. Zwarts wrote:
    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.


    Olcott's own words are that the simulation of D never reaches past
    line 03. So the lines following line 03 do not play a role and,
    therefore, can be removed without changing the claim. This leads to:

    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         return H(p, p);
    04       }
    05
    06       int main()
    07       {
    08         H(D,D);
    09         return 0;
    10       }


    What we see is that the only property of D that is used is that it is
    a parameter duplicator. (Is that why it is called D?). H needs 2
    parameters, but it can be given only one input parameter, so the
    parameter duplicator is required to allow H to decide about itself.



    Of the infinite set of H that simulate at least one step, none of
    them, when simulated by H, halts, because none of them reaches its
    final state. Olcott's claim is equivalent to the claim of non-halting
    behaviour of H.
    This means that a simulating halt-decider is a bad idea, because the
    decider itself does not halt.


    The simplification is valid.
    01       int D(ptr p)
    02       {
    03         H(p, p);
    04         return 0;
    05       }

    This is a better simplification because it now has an actual
    identifiable final state that can be separately referred to.
    It is not true that H never halts. H is required to be a pure
    function. https://en.wikipedia.org/wiki/Pure_function



    If H finds that H never halts and a non-halting H is not allowed, that
    it is clear that the set of H that satisfy the requirements is empty.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Sun May 26 16:43:58 2024
    XPost: comp.lang.c++

    Op 26.mei.2024 om 15:20 schreef olcott:
    On 5/26/2024 6:01 AM, Fred. Zwarts wrote:
    Op 26.mei.2024 om 06:19 schreef olcott:
    On 5/25/2024 2:32 AM, Fred. Zwarts wrote:
    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.


    Olcott's own words are that the simulation of D never reaches past
    line 03. So the lines following line 03 do not play a role and,
    therefore, can be removed without changing the claim. This leads to:

    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         return H(p, p);
    04       }
    05
    06       int main()
    07       {
    08         H(D,D);
    09         return 0;
    10       }


    What we see is that the only property of D that is used is that it
    is a parameter duplicator. (Is that why it is called D?). H needs 2
    parameters, but it can be given only one input parameter, so the
    parameter duplicator is required to allow H to decide about itself.



    Of the infinite set of H that simulate at least one step, none of
    them, when simulated by H, halts, because none of them reaches its
    final state. Olcott's claim is equivalent to the claim of
    non-halting behaviour of H.
    This means that a simulating halt-decider is a bad idea, because the
    decider itself does not halt.

    Not at all.
        A simulator is an x86 emulator that correctly emulates 1 to N of the >>>     x86 instructions of D in the order specified by the x86 instructions >>>     of D. This may include M recursive emulations of H emulating itself >>>     emulating D.

        This means that D cannot possibly reach its own line 06 and halt
        in any finite steps of correct simulation. H is free to halt at
        any time after these N finite steps of correct simulation.



    D does not reach it own line 04 because the simulation of H does not
    return to D. So, it shows that the simulation of H does not reach it
    final state, which proves that H does not halt.

    Your transformation would have been acceptable if you retained the
    fact that H is a pure function that always halts and returns some value.


    Since H is required to halt, but H shows that H does not halt (because
    the simulation of H never reaches its final state), the conclusion must
    be that there is no such H.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Mon May 27 10:57:32 2024
    XPost: comp.lang.c++

    Op 26.mei.2024 om 17:42 schreef olcott:
    On 5/26/2024 9:43 AM, Fred. Zwarts wrote:
    Op 26.mei.2024 om 15:20 schreef olcott:
    On 5/26/2024 6:01 AM, Fred. Zwarts wrote:
    Op 26.mei.2024 om 06:19 schreef olcott:
    On 5/25/2024 2:32 AM, Fred. Zwarts wrote:
    Op 23.mei.2024 om 18:52 schreef olcott:
    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 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.

    In the above case 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.


    Olcott's own words are that the simulation of D never reaches past >>>>>> line 03. So the lines following line 03 do not play a role and,
    therefore, can be removed without changing the claim. This leads to: >>>>>>
    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         return H(p, p);
    04       }
    05
    06       int main()
    07       {
    08         H(D,D);
    09         return 0;
    10       }


    What we see is that the only property of D that is used is that it >>>>>> is a parameter duplicator. (Is that why it is called D?). H needs
    2 parameters, but it can be given only one input parameter, so the >>>>>> parameter duplicator is required to allow H to decide about itself. >>>>>>


    Of the infinite set of H that simulate at least one step, none of
    them, when simulated by H, halts, because none of them reaches its >>>>>> final state. Olcott's claim is equivalent to the claim of
    non-halting behaviour of H.
    This means that a simulating halt-decider is a bad idea, because
    the decider itself does not halt.

    Not at all.
        A simulator is an x86 emulator that correctly emulates 1 to N >>>>> of the
        x86 instructions of D in the order specified by the x86
    instructions
        of D. This may include M recursive emulations of H emulating
    itself
        emulating D.

        This means that D cannot possibly reach its own line 06 and halt >>>>>     in any finite steps of correct simulation. H is free to halt at >>>>>     any time after these N finite steps of correct simulation.



    D does not reach it own line 04 because the simulation of H does not
    return to D. So, it shows that the simulation of H does not reach it
    final state, which proves that H does not halt.

    Your transformation would have been acceptable if you retained the
    fact that H is a pure function that always halts and returns some value. >>>

    Since H is required to halt, but H shows that H does not halt (because
    the simulation of H never reaches its final state), the conclusion
    must be that there is no such H.



    When D correctly simulated by pure simulator H remains stuck in infinite recursive simulation then we also know that D never reaches its own line
    06 and halts in less than an infinite number of correctly simulated
    steps.

    This is what I had in mind all along. Because I am a relatively terrible communicator it takes me a very long time to translate my intuitions
    into simple words.


    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 return H(p, p);
    04 }
    05
    06 int main()
    07 {
    08 H(D,D);
    09 return 0;
    10 }

    We see that the requirements for H are contradictory. H must simulate
    and H must halt, but the simulation of H never reaches it final state.
    We check that using H. The problem is that H requires two parameters,
    but it supplies only one parameter. So we use the parameter duplicator
    D. D is a simple function that is used only to allow H to check H
    itself. It is clear that if H halts, D halts too and if H does not halt,
    D does not halt either. It is also clear that when H simulates at least
    one step of H, the simulated H never reaches its final state. So, H must conclude that H satisfies non-termination criteria. Olcott claims that
    the question whether the direct execution of H halts is incorrect,
    because the simulation is what determines the halting of H and the
    simulation of H never reaches its final state. This shows that no H
    exists that simulates and halts.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)