• Refuting the HP proofs (adapted for software engineers)

    From olcott@21:1/5 to All on Fri Jun 3 17:17:12 2022
    XPost: comp.theory, comp.lang.c, comp.lang.c++

    This post assumes that you already know my work, otherwise please read
    the linked paper provided below. This work is based on the x86utm
    operating system that was created so that every detail of the halting
    problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
    HERE: goto HERE;
    }

    int main()
    {
    Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01) 55 push ebp
    [00001343](02) 8bec mov ebp,esp
    [00001345](02) ebfe jmp 00001345
    [00001347](01) 5d pop ebp
    [00001348](01) c3 ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret" instruction).

    Equally obvious is the fact that a partial x86 emulation of this input conclusively proves that its complete x86 emulation would never halt.

    Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to H(P,P):

    _P()
    [00001352](01) 55 push ebp
    [00001353](02) 8bec mov ebp,esp
    [00001355](03) 8b4508 mov eax,[ebp+08]
    [00001358](01) 50 push eax // push P
    [00001359](03) 8b4d08 mov ecx,[ebp+08]
    [0000135c](01) 51 push ecx // push P
    [0000135d](05) e840feffff call 000011a2 // call H
    [00001362](03) 83c408 add esp,+08
    [00001365](02) 85c0 test eax,eax
    [00001367](02) 7402 jz 0000136b
    [00001369](02) ebfe jmp 00001369
    [0000136b](01) 5d pop ebp
    [0000136c](01) c3 ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its input
    that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know with
    complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5



    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Jun 3 18:50:42 2022
    XPost: comp.theory, sci.logic

    On 6/3/22 6:17 PM, olcott wrote:
    This post assumes that you already know my work, otherwise please read
    the linked paper provided below. This work is based on the x86utm
    operating system that was created so that every detail of the halting
    problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
      HERE: goto HERE;
    }

    int main()
    {
      Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01)  55              push ebp
    [00001343](02)  8bec            mov ebp,esp
    [00001345](02)  ebfe            jmp 00001345
    [00001347](01)  5d              pop ebp
    [00001348](01)  c3              ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret" instruction).

    Equally obvious is the fact that a partial x86 emulation of this input conclusively proves that its complete x86 emulation would never halt.

    Begin Local Halt Decider Simulation   Execution Trace Stored at:212343 [00001342][00212333][00212337] 55         push ebp [00001343][00212333][00212337] 8bec       mov ebp,esp [00001345][00212333][00212337] ebfe       jmp 00001345 [00001345][00212333][00212337] ebfe       jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to H(P,P):

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax      // push P [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx      // push P [0000135d](05)  e840feffff      call 000011a2 // call H [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its input
    that it must emulate the first seven instructions of P.

    Maybe, but then it needs to emulate the eight instruction of the program
    P which is at 000011a2, which you never show.


    Because the seventh instruction repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.

    Nope. You NEVER have actually shown a correct simulation of the program.

    At least, the second "round" of simulation needs to be marked as "a
    conditional simulation of the simulation of" the code you list.

    Your example with Infinite_Loop doesn't translate to the simulation of
    P(P) as there is no actual correct "infinite behavior" pattern that H
    has seen, inpart because you ignore that the later rounds of simulation
    are ALL conditional based on the simulated H doing its simulation
    conditionally based on its halt decision rules.

    This means that there actually is NO correct non-halting pattern in the simulation it sees, so when it does abort, it does so incorrectly, or if
    it never aborts, it fails to answer.

    This has been explained to you many times, but you seem incapable of
    actually learning by your mistakes, maybe because you have made yoursef intentionally ignorant of the actual rules of logic, or maybe because
    you are just a pathological liar.

    FAIL.




    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to olcott on Sat Jun 4 00:36:53 2022
    XPost: comp.theory, sci.logic, comp.software-eng

    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please
    read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the
    halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
    HERE: goto HERE;
    }

    int main()
    {
    Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01) 55 push ebp
    [00001343](02) 8bec mov ebp,esp
    [00001345](02) ebfe jmp 00001345
    [00001347](01) 5d pop ebp
    [00001348](01) c3 ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this
    input conclusively proves that its complete x86 emulation would never
    halt.

    Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to
    H(P,P):

    _P()
    [00001352](01) 55 push ebp
    [00001353](02) 8bec mov ebp,esp
    [00001355](03) 8b4508 mov eax,[ebp+08]
    [00001358](01) 50 push eax // push P
    [00001359](03) 8b4d08 mov ecx,[ebp+08]
    [0000135c](01) 51 push ecx // push P
    [0000135d](05) e840feffff call 000011a2 // call H
    [00001362](03) 83c408 add esp,+08
    [00001365](02) 85c0 test eax,eax
    [00001367](02) 7402 jz 0000136b
    [00001369](02) ebfe jmp 00001369
    [0000136b](01) 5d pop ebp
    [0000136c](01) c3 ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its
    input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

    Unfortunately your logic is such that the decision as to whether or not
    to enter the infinite loop is predicated on an infinite recursion (call
    H) that is not present in the Halting Problem proofs you are attempting
    to refute.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to olcott on Sat Jun 4 00:35:02 2022
    XPost: comp.theory, sci.logic, comp.software-eng

    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please
    read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the
    halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
    HERE: goto HERE;
    }

    int main()
    {
    Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01) 55 push ebp
    [00001343](02) 8bec mov ebp,esp
    [00001345](02) ebfe jmp 00001345
    [00001347](01) 5d pop ebp
    [00001348](01) c3 ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this
    input conclusively proves that its complete x86 emulation would never
    halt.

    Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to
    H(P,P):

    _P()
    [00001352](01) 55 push ebp
    [00001353](02) 8bec mov ebp,esp
    [00001355](03) 8b4508 mov eax,[ebp+08]
    [00001358](01) 50 push eax // push P
    [00001359](03) 8b4d08 mov ecx,[ebp+08]
    [0000135c](01) 51 push ecx // push P
    [0000135d](05) e840feffff call 000011a2 // call H
    [00001362](03) 83c408 add esp,+08
    [00001365](02) 85c0 test eax,eax
    [00001367](02) 7402 jz 0000136b
    [00001369](02) ebfe jmp 00001369
    [0000136b](01) 5d pop ebp
    [0000136c](01) c3 ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its
    input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

    Unfortunately your logic is such that the decision as to whether or not
    to enter the infinite loop is predicated on an infinite recursion (call
    H) that is not present in the Halting Problem proofs you are attempting
    to refute.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Mr Flibble on Fri Jun 3 18:56:15 2022
    XPost: comp.theory, sci.logic, comp.software-eng

    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please
    read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the
    halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
    HERE: goto HERE;
    }

    int main()
    {
    Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01) 55 push ebp
    [00001343](02) 8bec mov ebp,esp
    [00001345](02) ebfe jmp 00001345
    [00001347](01) 5d pop ebp
    [00001348](01) c3 ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this
    input conclusively proves that its complete x86 emulation would never
    halt.

    Begin Local Halt Decider Simulation Execution Trace Stored at:212343
    [00001342][00212333][00212337] 55 push ebp
    [00001343][00212333][00212337] 8bec mov ebp,esp
    [00001345][00212333][00212337] ebfe jmp 00001345
    [00001345][00212333][00212337] ebfe jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to
    H(P,P):

    _P()
    [00001352](01) 55 push ebp
    [00001353](02) 8bec mov ebp,esp
    [00001355](03) 8b4508 mov eax,[ebp+08]
    [00001358](01) 50 push eax // push P
    [00001359](03) 8b4d08 mov ecx,[ebp+08]
    [0000135c](01) 51 push ecx // push P
    [0000135d](05) e840feffff call 000011a2 // call H
    [00001362](03) 83c408 add esp,+08
    [00001365](02) 85c0 test eax,eax
    [00001367](02) 7402 jz 0000136b
    [00001369](02) ebfe jmp 00001369
    [0000136b](01) 5d pop ebp
    [0000136c](01) c3 ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its
    input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know with
    complete certainty that the emulated P never reaches its final “ret”
    instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

    Unfortunately your logic is such that the decision as to whether or not
    to enter the infinite loop is predicated on an infinite recursion (call
    H) that is not present in the Halting Problem proofs you are attempting
    to refute.

    /Flibble


    It is when a simulating halt decider is assumed.

    No one ever bothered to think the otherwise "impossible" input being
    analyzed by a simulating halt decider ALL THE WAY THROUGH EVER BEFORE!

    On 6/2/2022 1:12 PM, Andy Walker wrote:
    http://www.cuboid.me.uk/anw/G12FCO/lect18.html
    At any given moment as the emulation proceeds, we are in one of not two
    but three states: the program has halted, or it is looping, or it is
    still running and has not yet entered a loop. It's the third case that
    kills us -- we just have to keep going, and wait for one of the other
    two things to happen. The trouble is that it may be that neither of them
    ever happens -- which is why `it must be in a loop' was in quotes above.

    Andy Walker did provide a fundamentally flawed and totally shallow
    analysis of an simulating halt decider.

    At any given moment as the emulation proceeds,
    we are in one of not two but three states:
    (a) The program has halted,
    (b) It is still running.
    (c) IT HAS MATCHED AN INFINITE BEHAVIOR PATTERN

    void P(u32 x)
    {
    if (H(x, x))
    HERE: goto HERE;
    return;
    }

    The above matches (c) for infinitely nested simulation.

    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Jun 3 20:20:51 2022
    XPost: comp.theory, sci.logic

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please
    read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the
    halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
        HERE: goto HERE;
    }

    int main()
    {
        Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01)  55              push ebp
    [00001343](02)  8bec            mov ebp,esp
    [00001345](02)  ebfe            jmp 00001345
    [00001347](01)  5d              pop ebp
    [00001348](01)  c3              ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this
    input conclusively proves that its complete x86 emulation would never
    halt.

    Begin Local Halt Decider Simulation   Execution Trace Stored at:212343 >>> [00001342][00212333][00212337] 55         push ebp
    [00001343][00212333][00212337] 8bec       mov ebp,esp
    [00001345][00212333][00212337] ebfe       jmp 00001345
    [00001345][00212333][00212337] ebfe       jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to
    H(P,P):

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax      // push P >>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx      // push P >>> [0000135d](05)  e840feffff      call 000011a2 // call H
    [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its
    input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know with
    complete certainty that the emulated P never reaches its final “ret” >>> instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


    Unfortunately your logic is such that the decision as to whether or not
    to enter the infinite loop is predicated on an infinite recursion (call
    H) that is not present in the Halting Problem proofs you are attempting
    to refute.

    /Flibble


    It is when a simulating halt decider is assumed.

    But you can not assume that an actual simulating Halt Decider actually
    exists.


    No one ever bothered to think the otherwise "impossible" input being
    analyzed by a simulating halt decider ALL THE WAY THROUGH EVER BEFORE!





    On 6/2/2022 1:12 PM, Andy Walker wrote:
      http://www.cuboid.me.uk/anw/G12FCO/lect18.html
    At any given moment as the emulation proceeds, we are in one of not two
    but three states: the program has halted, or it is looping, or it is
    still running and has not yet entered a loop. It's the third case that
    kills us -- we just have to keep going, and wait for one of the other
    two things to happen. The trouble is that it may be that neither of them
    ever happens -- which is why `it must be in a loop' was in quotes above.

    Andy Walker did provide a fundamentally flawed and totally shallow
    analysis of an simulating halt decider.

    At any given moment as the emulation proceeds,
    we are in one of not two but three states:
    (a) The program has halted,
    (b) It is still running.
    (c) IT HAS MATCHED AN INFINITE BEHAVIOR PATTERN

    void P(u32 x)
    {
      if (H(x, x))
        HERE: goto HERE;
      return;
    }

    The above matches (c) for infinitely nested simulation.


    Nope, you NEVER get to (C) if H can abort its simulation, since if
    H(P,P) will abort its simulation and return 0, then BY DEFINITON P(P) is Halting, and thus the CORRECT answer for H(P,P) is 1.


    You can show you get to (c) if H is defined to never abort, but if H is
    defined to never abort, it can't then abort and return the answer.

    The problem is that when H is defined to abort on ANY finite pattern you
    might imagine to be a "correct infinite behavior pattern", then that
    pattern is actually proved to not be correct.

    The problem is you need to do the analysis looking at the H(P,P) called
    by P(P) as being able to what it actually ends up doing. Thus, if you
    postulate the top level H(P,P) aborting its simulation for detecting a
    pattern, you need to show that pattern actually does exist when the H
    that it is simulating will do the same thing.

    The pattern you are think of doesn't consider that case, but assumes
    that H NEVER (and not just "Not yet") aborts its simulation, and thus is
    not applicable here.

    The problem appears because the trace you "show" isn't correct, but is
    edited and removes the evidence of the conditionality of the "nested" simulations.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Fri Jun 3 22:51:08 2022
    XPost: comp.theory, sci.logic

    On 6/3/2022 7:20 PM, Richard Damon wrote:

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please
    read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the
    halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
        HERE: goto HERE;
    }

    int main()
    {
        Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01)  55              push ebp
    [00001343](02)  8bec            mov ebp,esp
    [00001345](02)  ebfe            jmp 00001345
    [00001347](01)  5d              pop ebp
    [00001348](01)  c3              ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this
    input conclusively proves that its complete x86 emulation would never
    halt.

    Begin Local Halt Decider Simulation   Execution Trace Stored at:212343 >>>> [00001342][00212333][00212337] 55         push ebp
    [00001343][00212333][00212337] 8bec       mov ebp,esp
    [00001345][00212333][00212337] ebfe       jmp 00001345
    [00001345][00212333][00212337] ebfe       jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to
    H(P,P):

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax      // push P >>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx      // push P >>>> [0000135d](05)  e840feffff      call 000011a2 // call H
    [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its
    input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know with
    complete certainty that the emulated P never reaches its final “ret” >>>> instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


    Unfortunately your logic is such that the decision as to whether or not
    to enter the infinite loop is predicated on an infinite recursion (call
    H) that is not present in the Halting Problem proofs you are attempting
    to refute.

    /Flibble


    It is when a simulating halt decider is assumed.

    But you can not assume that an actual simulating Halt Decider actually exists.

    I proved that H(P,P)==0 is correct.

    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat Jun 4 06:27:46 2022
    XPost: comp.theory, sci.logic

    On 6/3/22 11:51 PM, olcott wrote:
    On 6/3/2022 7:20 PM, Richard Damon wrote:

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please
    read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the >>>>> halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
        HERE: goto HERE;
    }

    int main()
    {
        Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01)  55              push ebp
    [00001343](02)  8bec            mov ebp,esp
    [00001345](02)  ebfe            jmp 00001345
    [00001347](01)  5d              pop ebp
    [00001348](01)  c3              ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this
    input conclusively proves that its complete x86 emulation would never >>>>> halt.

    Begin Local Halt Decider Simulation   Execution Trace Stored at:212343 >>>>> [00001342][00212333][00212337] 55         push ebp
    [00001343][00212333][00212337] 8bec       mov ebp,esp
    [00001345][00212333][00212337] ebfe       jmp 00001345
    [00001345][00212333][00212337] ebfe       jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to
    H(P,P):

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax      // push P
    [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx      // push P
    [0000135d](05)  e840feffff      call 000011a2 // call H
    [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its
    input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know with >>>>> complete certainty that the emulated P never reaches its final “ret” >>>>> instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5) >>>>>
    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


    Unfortunately your logic is such that the decision as to whether or not >>>> to enter the infinite loop is predicated on an infinite recursion (call >>>> H) that is not present in the Halting Problem proofs you are attempting >>>> to refute.

    /Flibble


    It is when a simulating halt decider is assumed.

    But you can not assume that an actual simulating Halt Decider actually
    exists.

    I proved that H(P,P)==0 is correct.


    No, not for the ACTUAL halting problem.

    You have shown that H(P,P) == 0 is correct if the problem is can H
    simulate its input to a final state, not does that input, when actually
    run (or correctly simulate by the actual definition of correct
    simulation) reach a final state.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Malcolm McLean on Sat Jun 4 10:11:27 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/4/2022 5:01 AM, Malcolm McLean wrote:
    On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
    On 6/3/2022 7:20 PM, Richard Damon wrote:

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <No...@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please
    read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the >>>>>> halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
    HERE: goto HERE;
    }

    int main()
    {
    Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01) 55 push ebp
    [00001343](02) 8bec mov ebp,esp
    [00001345](02) ebfe jmp 00001345
    [00001347](01) 5d pop ebp
    [00001348](01) c3 ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this
    input conclusively proves that its complete x86 emulation would never >>>>>> halt.

    Begin Local Halt Decider Simulation Execution Trace Stored at:212343 >>>>>> [00001342][00212333][00212337] 55 push ebp
    [00001343][00212333][00212337] 8bec mov ebp,esp
    [00001345][00212333][00212337] ebfe jmp 00001345
    [00001345][00212333][00212337] ebfe jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to >>>>>> H(P,P):

    _P()
    [00001352](01) 55 push ebp
    [00001353](02) 8bec mov ebp,esp
    [00001355](03) 8b4508 mov eax,[ebp+08]
    [00001358](01) 50 push eax // push P
    [00001359](03) 8b4d08 mov ecx,[ebp+08]
    [0000135c](01) 51 push ecx // push P
    [0000135d](05) e840feffff call 000011a2 // call H
    [00001362](03) 83c408 add esp,+08
    [00001365](02) 85c0 test eax,eax
    [00001367](02) 7402 jz 0000136b
    [00001369](02) ebfe jmp 00001369
    [0000136b](01) 5d pop ebp
    [0000136c](01) c3 ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its
    input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know with >>>>>> complete certainty that the emulated P never reaches its final “ret” >>>>>> instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5) >>>>>>
    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


    Unfortunately your logic is such that the decision as to whether or not >>>>> to enter the infinite loop is predicated on an infinite recursion (call >>>>> H) that is not present in the Halting Problem proofs you are attempting >>>>> to refute.

    /Flibble


    It is when a simulating halt decider is assumed.

    But you can not assume that an actual simulating Halt Decider actually
    exists.
    I proved that H(P,P)==0 is correct.

    You've got nested simulations.
    If H detects them as infinitely nested, and aborts, they are no longer infinitely
    nested, so it gets the wrong answer (as happens here).

    I can't understand how you can be so wrong about this. It is like you
    make sure to never read anything that I say before spouting off a canned rebuttal.

    void Infinite_Loop()
    {
    HERE: goto HERE;
    }

    int main()
    {
    Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01) 55 push ebp
    [00001343](02) 8bec mov ebp,esp
    [00001345](02) ebfe jmp 00001345
    [00001347](01) 5d pop ebp
    [00001348](01) c3 ret
    Size in bytes:(0007) [00001348]

    In the same way that H0 detects that the complete x86 emulation of _Infinite_Loop() would never reach its final "ret" instruction H(P,P) on
    the basis of a partial simulation H(P,P) detects that the complete x86 emulation of its input would never reach its final "ret" instruction.

    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?

    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING

    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY

    If H doesn't detects them as infinitely nested, and never aborts, H simulates forever, because they are infinitely nested.

    Either way, H gets it wrong.


    So you are saying that it is impossible for H0 to correctly detect that _Infinite_Loop() would never reach its final "ret" instruction because
    as soon _Infinite_Loop() has had its simulation aborted it magically
    leaps to its "ret" instruction.

    My own view is that you've actually got something interesting here. That isn't
    shared by other posters, probably because you've put them off by claims to have
    "solved the halting problem", repeated at great length.


    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Sat Jun 4 10:28:56 2022
    XPost: comp.theory, sci.logic

    On 6/4/2022 5:27 AM, Richard Damon wrote:
    On 6/3/22 11:51 PM, olcott wrote:
    On 6/3/2022 7:20 PM, Richard Damon wrote:

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please
    read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the >>>>>> halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
        HERE: goto HERE;
    }

    int main()
    {
        Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01)  55              push ebp
    [00001343](02)  8bec            mov ebp,esp
    [00001345](02)  ebfe            jmp 00001345
    [00001347](01)  5d              pop ebp
    [00001348](01)  c3              ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt
    (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this
    input conclusively proves that its complete x86 emulation would never >>>>>> halt.

    Begin Local Halt Decider Simulation   Execution Trace Stored
    at:212343
    [00001342][00212333][00212337] 55         push ebp
    [00001343][00212333][00212337] 8bec       mov ebp,esp
    [00001345][00212333][00212337] ebfe       jmp 00001345
    [00001345][00212333][00212337] ebfe       jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to >>>>>> H(P,P):

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax      // push P
    [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx      // push P
    [0000135d](05)  e840feffff      call 000011a2 // call H
    [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its
    input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know with >>>>>> complete certainty that the emulated P never reaches its final “ret” >>>>>> instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5) >>>>>>
    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


    Unfortunately your logic is such that the decision as to whether or
    not
    to enter the infinite loop is predicated on an infinite recursion
    (call
    H) that is not present in the Halting Problem proofs you are
    attempting
    to refute.

    /Flibble


    It is when a simulating halt decider is assumed.

    But you can not assume that an actual simulating Halt Decider
    actually exists.

    I proved that H(P,P)==0 is correct.


    No, not for the ACTUAL halting problem.

    You have shown that H(P,P) == 0 is correct if the problem is can H
    simulate its input to a final state,


    THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
    H computes the mapping from its input finite strings to its accept or
    reject state on the basis of the actual behavior specified by the actual
    input as measured by the correct x86 emulation of this input by H.

    not does that input, when actually
    run (or correctly simulate by the actual definition of correct
    simulation) reach a final state.

    int sum(int x, int y)
    {
    return x + y;
    }

    It as is nutty to say that H(P,P) must return a value that does not
    correspond to its input as it is to expect sum(3,4) to return 23.

    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat Jun 4 11:51:19 2022
    XPost: comp.theory, sci.logic

    On 6/4/22 11:28 AM, olcott wrote:
    On 6/4/2022 5:27 AM, Richard Damon wrote:
    On 6/3/22 11:51 PM, olcott wrote:
    On 6/3/2022 7:20 PM, Richard Damon wrote:

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please >>>>>>> read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the >>>>>>> halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
        HERE: goto HERE;
    }

    int main()
    {
        Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01)  55              push ebp
    [00001343](02)  8bec            mov ebp,esp
    [00001345](02)  ebfe            jmp 00001345
    [00001347](01)  5d              pop ebp
    [00001348](01)  c3              ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt >>>>>>> (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this >>>>>>> input conclusively proves that its complete x86 emulation would
    never
    halt.

    Begin Local Halt Decider Simulation   Execution Trace Stored
    at:212343
    [00001342][00212333][00212337] 55         push ebp
    [00001343][00212333][00212337] 8bec       mov ebp,esp
    [00001345][00212333][00212337] ebfe       jmp 00001345
    [00001345][00212333][00212337] ebfe       jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to >>>>>>> H(P,P):

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax      // push P
    [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx      // push P
    [0000135d](05)  e840feffff      call 000011a2 // call H
    [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its >>>>>>> input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know >>>>>>> with
    complete certainty that the emulated P never reaches its final “ret”
    instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5) >>>>>>>
    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


    Unfortunately your logic is such that the decision as to whether
    or not
    to enter the infinite loop is predicated on an infinite recursion
    (call
    H) that is not present in the Halting Problem proofs you are
    attempting
    to refute.

    /Flibble


    It is when a simulating halt decider is assumed.

    But you can not assume that an actual simulating Halt Decider
    actually exists.

    I proved that H(P,P)==0 is correct.


    No, not for the ACTUAL halting problem.

    You have shown that H(P,P) == 0 is correct if the problem is can H
    simulate its input to a final state,


    THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
    H computes the mapping from its input finite strings to its accept or
    reject state on the basis of the actual behavior specified by the actual input as measured by the correct x86 emulation of this input by H.

    Ok, since your problem statement NEVER mentions the Halting Property, I
    guess that means you are admitting you aren't actually working on the
    Halting Property.

    Also, since the only valid defintion of a "correct x86 emulation" must
    behave exactly the same that input when run by an x86 processor, the
    ONLY way that H can actually DO that is to never abort until it reaches
    the final state, even if that takes forever.

    H also needs to be a DEFINITE piece of code, so at can only have a
    single behavior for a given input.

    Thus, you definition is just shown to be flawed, as H CAN'T both create
    a "correct x86 emulation" of the input P,P and also compute a mapping in
    finite time,

    Either you H fails to correctly emulate its input by deciding early that
    its input would not halt, (this can be shown by an actual correct
    emulation of that input reaching the halting state), or your H fails to
    map this input to an acccept or reject state.

    Thus, your definition is just like the Liar's Paradox, it doesn't
    actually have a truth value because it just can't exist as stated.


    not does that input, when actually run (or correctly simulate by the
    actual definition of correct simulation) reach a final state.

    int sum(int x, int y)
    {
      return x + y;
    }

    It as is nutty to say that H(P,P) must return a value that does not correspond to its input as it is to expect sum(3,4) to return 23.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat Jun 4 11:38:38 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/4/22 11:11 AM, olcott wrote:
    On 6/4/2022 5:01 AM, Malcolm McLean wrote:
    On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
    On 6/3/2022 7:20 PM, Richard Damon wrote:

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <No...@NoWhere.com> wrote:

    This post assumes that you already know my work, otherwise please >>>>>>> read the linked paper provided below. This work is based on the
    x86utm operating system that was created so that every detail of the >>>>>>> halting problem could be directly examined in C/x86.

    void Infinite_Loop()
    {
         HERE: goto HERE;
    }

    int main()
    {
         Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01)  55              push ebp
    [00001343](02)  8bec            mov ebp,esp
    [00001345](02)  ebfe            jmp 00001345
    [00001347](01)  5d              pop ebp
    [00001348](01)  c3              ret
    Size in bytes:(0007) [00001348]

    It is totally obvious that the _Infinite_Loop() would never halt >>>>>>> (meaning that it terminates normally by reaching its "ret"
    instruction).

    Equally obvious is the fact that a partial x86 emulation of this >>>>>>> input conclusively proves that its complete x86 emulation would
    never
    halt.

    Begin Local Halt Decider Simulation   Execution Trace Stored
    at:212343
    [00001342][00212333][00212337] 55         push ebp
    [00001343][00212333][00212337] 8bec       mov ebp,esp
    [00001345][00212333][00212337] ebfe       jmp 00001345
    [00001345][00212333][00212337] ebfe       jmp 00001345
    Local Halt Decider: Infinite Loop Detected Simulation Stopped

    The exact same reasoning applies to the correctly emulated input to >>>>>>> H(P,P):

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax      // push P
    [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx      // push P
    [0000135d](05)  e840feffff      call 000011a2 // call H
    [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its >>>>>>> input that it must emulate the first seven instructions of P.

    Because the seventh instruction repeats this process we can know >>>>>>> with
    complete certainty that the emulated P never reaches its final “ret”
    instruction, thus never halts.



    Halting problem undecidability and infinitely nested simulation (V5) >>>>>>>
    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5



    Unfortunately your logic is such that the decision as to whether
    or not
    to enter the infinite loop is predicated on an infinite recursion
    (call
    H) that is not present in the Halting Problem proofs you are
    attempting
    to refute.

    /Flibble


    It is when a simulating halt decider is assumed.

    But you can not assume that an actual simulating Halt Decider actually >>>> exists.
    I proved that H(P,P)==0 is correct.

    You've got nested simulations.
    If H detects them as infinitely nested, and aborts, they are no longer
    infinitely
    nested, so it gets the wrong answer (as happens here).

    I can't understand how you can be so wrong about this. It is like you
    make sure to never read anything that I say before spouting off a canned rebuttal.

    void Infinite_Loop()
    {
      HERE: goto HERE;
    }

    int main()
    {
      Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01)  55              push ebp
    [00001343](02)  8bec            mov ebp,esp
    [00001345](02)  ebfe            jmp 00001345
    [00001347](01)  5d              pop ebp
    [00001348](01)  c3              ret
    Size in bytes:(0007) [00001348]

    In the same way that H0 detects that the complete x86 emulation of _Infinite_Loop() would never reach its final "ret" instruction H(P,P) on
    the basis of a partial simulation H(P,P) detects that the complete x86 emulation of its input would never reach its final "ret" instruction.

    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?

    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING

    Right, and for the simulation of H(P,P), that is all that happen



    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY


    And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.


    If H doesn't detects them as infinitely nested, and never aborts, H
    simulates
    forever, because they are infinitely nested.

    Either way, H gets it wrong.


    So you are saying that it is impossible for H0 to correctly detect that _Infinite_Loop() would never reach its final "ret" instruction because
    as soon _Infinite_Loop() has had its simulation aborted it magically
    leaps to its "ret" instruction.

    Nope, he NEVER said that. You apparently just can't read, and thus prove
    your stupidity.

    You keep on making this mistake, that when people say your H can't do
    one thing about P, that you say "Are you saying it can't do it for this
    other trivial program?"

    You are a great example of someone using many different logical
    fallicies in their arguement.

    You use them SO well, it really seems to be deliberate.

    All you have proved so far is that you just don't understand how to do
    proper logical arguments, and are appatently way out of your depth in
    what you are talking about.


    My own view is that you've actually got something interesting here.
    That isn't
    shared by other posters, probably because you've put them off by
    claims to have
    "solved the halting problem", repeated at great length.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Muttley@dastardlyhq.com on Sat Jun 4 11:14:19 2022
    XPost: comp.lang.c, comp.lang.c++

    On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:
    This post assumes that you already know my work, otherwise please read
    the linked paper provided below. This work is based on the x86utm

    Thanks, but I need to go watch some paint dry. Maybe next time.



    Until the notion of truth itself is formalized research in artificial intelligence is hobbled.

    A correct refutation of the halting problem proofs also refutes the
    Tarski undefinability theorem by proxy, thus enabling the notion of
    truth to be formalized.

    This anchors the basis of Davidson's truth conditional semantics. This
    creates the roadmap for artificial intelligence with unlimited potential.

    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5




    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alan Mackenzie@21:1/5 to olcott on Sat Jun 4 18:17:15 2022
    XPost: comp.theory, sci.logic, sci.math

    [ Followup-To: set ]

    In comp.theory olcott <NoOne@nowhere.com> wrote:
    On 6/4/2022 5:01 AM, Malcolm McLean wrote:
    On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
    On 6/3/2022 7:20 PM, Richard Damon wrote:

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <No...@NoWhere.com> wrote:

    [ .... ]

    You've got nested simulations.
    If H detects them as infinitely nested, and aborts, they are no longer
    infinitely nested, so it gets the wrong answer (as happens here).

    I can't understand how you can be so wrong about this. It is like you
    make sure to never read anything that I say before spouting off a canned rebuttal.

    I frequently read what you say. It's dull and repetitive. And wrong.

    void Infinite_Loop()
    {
    HERE: goto HERE;
    }

    int main()
    {
    Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01) 55 push ebp
    [00001343](02) 8bec mov ebp,esp
    [00001345](02) ebfe jmp 00001345
    [00001347](01) 5d pop ebp
    [00001348](01) c3 ret
    Size in bytes:(0007) [00001348]

    In the same way that H0 detects .....

    We don't know what H0 detects, since its code is secret, and probably
    doesn't exist.

    .... that the complete x86 emulation of _Infinite_Loop() would never
    reach its final "ret" instruction H(P,P) on the basis of a partial
    simulation H(P,P) detects that the complete x86 emulation of its input
    would never reach its final "ret" instruction.

    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?

    Yes. It's dull and repetitive and wrong. If it were correct, you would
    only need to say it once, and it would be accepted and acknowledged by
    the experts in this group.

    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING

    In this context, it does.

    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY

    A turing machine runs until it halts. Terminated "normally" has no
    meaning. That is one reason you avoid turing machines. They make things
    too clear and well defined, leaving you no room to argue stupidities like "halting doesn't mean stops running".

    If H doesn't detects them as infinitely nested, and never aborts, H
    simulates forever, because they are infinitely nested.

    Either way, H gets it wrong.

    So you are saying that it is impossible for H0 to correctly detect that _Infinite_Loop() would never reach its final "ret" instruction because
    as soon _Infinite_Loop() has had its simulation aborted it magically
    leaps to its "ret" instruction.

    Wrong. That is not what he is saying. He is saying that H gets it
    wrong, explaining why.

    [ .... ]

    --
    Copyright 2022 Pete Olcott

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

    --
    Alan Mackenzie (Nuremberg, Germany).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat Jun 4 16:05:37 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/4/22 3:28 PM, olcott wrote:
    On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
    [ Followup-To: set ]

    In comp.theory olcott <NoOne@nowhere.com> wrote:
    On 6/4/2022 5:01 AM, Malcolm McLean wrote:
    On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
    On 6/3/2022 7:20 PM, Richard Damon wrote:

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <No...@NoWhere.com> wrote:

    [ .... ]

    You've got nested simulations.
    If H detects them as infinitely nested, and aborts, they are no longer >>>> infinitely nested, so it gets the wrong answer (as happens here).

    I can't understand how you can be so wrong about this. It is like you
    make sure to never read anything that I say before spouting off a canned >>> rebuttal.

    I frequently read what you say.  It's dull and repetitive.  And wrong.

    void Infinite_Loop()
    {
       HERE: goto HERE;
    }

    int main()
    {
       Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01)  55              push ebp
    [00001343](02)  8bec            mov ebp,esp
    [00001345](02)  ebfe            jmp 00001345
    [00001347](01)  5d              pop ebp
    [00001348](01)  c3              ret
    Size in bytes:(0007) [00001348]

    In the same way that H0 detects .....

    We don't know what H0 detects, since its code is secret, and probably
    doesn't exist.

    .... that the complete x86 emulation of _Infinite_Loop() would never
    reach its final "ret" instruction H(P,P) on the basis of a partial
    simulation H(P,P) detects that the complete x86 emulation of its input
    would never reach its final "ret" instruction.

    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?

    Yes.  It's dull and repetitive and wrong.  If it were correct, you would >> only need to say it once, and it would be accepted and acknowledged by
    the experts in this group.

    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING

    In this context, it does.

    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY

    A turing machine runs until it halts.  Terminated "normally" has no
    meaning.

    A Turing machine is said to halt whenever it reaches a configuration for which δ is not defined; this is possible because δ is a partial
    function. In fact, we will assume that no transitions are defined for
    any final state so the Turing machine will halt whenever it enters a
    final state.  (Linz:1990:234)

    Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company.


    Yes, it appears that Linz is using the notation that any unspecified
    transition is the signal that the machine halts where it is, as opposed
    to the notation with a defined set of final states (which have no
    transitions specified, and all other states have ALL transitions
    specified). These are "equivalent" descriptions in terms of computing
    power unless you are playing Turing Golf and scoring based on the "size"
    of the Turing Machine.

    When translated into ordinary software engineering terms this means terminated normally. In a C function this means reaching the "ret" instruction.

    That is one reason you avoid turing machines.  They make things
    too clear and well defined, leaving you no room to argue stupidities like
    "halting doesn't mean stops running".

    The reason that I avoid Turing machines is that 99% of the most
    important details cannot be fully expressed or analyzed. After all of
    these details are fully understood then it is very easy to apply the
    same reasoning to the Linz proof as I have done in my paper.

    No, you avoid them because you can't pull the shenanagians with them
    that you do with your x86 code. The key here is that a Turing Machine,
    by its very nature, can only be a computation, while x86 code fragments
    can easily be non-computations. By all appearances, you decider H is NOT actually a computation, and the only way for you to actually prove it is
    would be to let others inspect your code, but that would let the cat out
    of the bag (which you will probably call a dog).


    I suspect that also, you just don't understand how a Turing Machine
    actually works, because you are such a poor programmer you can't deal
    with a machine that won't take your dirty tricks. Maybe the issue is you
    have tried to code your trick as a Turing Machine, and because you can't
    make a non-computation out of one, you just failed and don't want to
    admit that you are just being a cheater.



    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Alan Mackenzie on Sat Jun 4 14:28:19 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
    [ Followup-To: set ]

    In comp.theory olcott <NoOne@nowhere.com> wrote:
    On 6/4/2022 5:01 AM, Malcolm McLean wrote:
    On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
    On 6/3/2022 7:20 PM, Richard Damon wrote:

    On 6/3/22 7:56 PM, olcott wrote:
    On 6/3/2022 6:35 PM, Mr Flibble wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <No...@NoWhere.com> wrote:

    [ .... ]

    You've got nested simulations.
    If H detects them as infinitely nested, and aborts, they are no longer
    infinitely nested, so it gets the wrong answer (as happens here).

    I can't understand how you can be so wrong about this. It is like you
    make sure to never read anything that I say before spouting off a canned
    rebuttal.

    I frequently read what you say. It's dull and repetitive. And wrong.

    void Infinite_Loop()
    {
    HERE: goto HERE;
    }

    int main()
    {
    Output("Input_Halts = ", H0(Infinite_Loop));
    }

    _Infinite_Loop()
    [00001342](01) 55 push ebp
    [00001343](02) 8bec mov ebp,esp
    [00001345](02) ebfe jmp 00001345
    [00001347](01) 5d pop ebp
    [00001348](01) c3 ret
    Size in bytes:(0007) [00001348]

    In the same way that H0 detects .....

    We don't know what H0 detects, since its code is secret, and probably
    doesn't exist.

    .... that the complete x86 emulation of _Infinite_Loop() would never
    reach its final "ret" instruction H(P,P) on the basis of a partial
    simulation H(P,P) detects that the complete x86 emulation of its input
    would never reach its final "ret" instruction.

    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?
    Did you notice that I said this 500 times already?

    Yes. It's dull and repetitive and wrong. If it were correct, you would
    only need to say it once, and it would be accepted and acknowledged by
    the experts in this group.

    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING
    HALTING DOES NOT MEAN STOPS RUNNING

    In this context, it does.

    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY
    HALTING MEANS TERMINATED NORMALLY

    A turing machine runs until it halts. Terminated "normally" has no
    meaning.

    A Turing machine is said to halt whenever it reaches a configuration for
    which δ is not defined; this is possible because δ is a partial
    function. In fact, we will assume that no transitions are defined for
    any final state so the Turing machine will halt whenever it enters a
    final state. (Linz:1990:234)

    Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company.

    When translated into ordinary software engineering terms this means
    terminated normally. In a C function this means reaching the "ret"
    instruction.

    That is one reason you avoid turing machines. They make things
    too clear and well defined, leaving you no room to argue stupidities like "halting doesn't mean stops running".

    The reason that I avoid Turing machines is that 99% of the most
    important details cannot be fully expressed or analyzed. After all of
    these details are fully understood then it is very easy to apply the
    same reasoning to the Linz proof as I have done in my paper.

    Halting problem undecidability and infinitely nested simulation (V5)

    https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5



    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeff Barnett@21:1/5 to Richard Damon on Sat Jun 4 17:30:52 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/4/2022 2:05 PM, Richard Damon wrote:

    <SNIP>

    Yes, it appears that Linz is using the notation that any unspecified transition is the signal that the machine halts where it is, as opposed
    to the notation with a defined set of final states (which have no
    transitions specified, and all other states have ALL transitions
    specified). These are "equivalent" descriptions in terms of computing
    power unless you are playing Turing Golf and scoring based on the "size"
    of the Turing Machine.

    The normal game is scored by the product of the number of states and the
    size of the tape (as opposed to the input) alphabet.
    --
    Jeff Barnett

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to olcott on Sun Jun 5 14:58:56 2022
    XPost: comp.lang.c, comp.lang.c++

    On Sat, 4 Jun 2022 11:14:19 -0500
    olcott <NoOne@NoWhere.com> wrote:
    On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:
    This post assumes that you already know my work, otherwise please read
    the linked paper provided below. This work is based on the x86utm

    Thanks, but I need to go watch some paint dry. Maybe next time.



    Until the notion of truth itself is formalized research in artificial >intelligence is hobbled.

    A correct refutation of the halting problem proofs also refutes the
    Tarski undefinability theorem by proxy, thus enabling the notion of
    truth to be formalized.

    This anchors the basis of Davidson's truth conditional semantics. This >creates the roadmap for artificial intelligence with unlimited potential.

    Halting problem undecidability and infinitely nested simulation (V5)

    You sound like the output of a simple markov chain chat bot thats been fed
    some doctorate level CS papers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Muttley@dastardlyhq.com on Sun Jun 5 15:05:17 2022
    XPost: comp.lang.c, comp.lang.c++

    On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:
    On Sat, 4 Jun 2022 11:14:19 -0500
    olcott <NoOne@NoWhere.com> wrote:
    On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:
    This post assumes that you already know my work, otherwise please read >>>> the linked paper provided below. This work is based on the x86utm

    Thanks, but I need to go watch some paint dry. Maybe next time.



    Until the notion of truth itself is formalized research in artificial
    intelligence is hobbled.

    A correct refutation of the halting problem proofs also refutes the
    Tarski undefinability theorem by proxy, thus enabling the notion of
    truth to be formalized.

    This anchors the basis of Davidson's truth conditional semantics. This
    creates the roadmap for artificial intelligence with unlimited potential.

    Halting problem undecidability and infinitely nested simulation (V5)

    You sound like the output of a simple markov chain chat bot thats been fed some doctorate level CS papers.


    I posted to this group because I have boiled down a key computer science problem into ordinary software engineering in C/x86.

    In computability theory, the halting problem is the problem of determining,
    from a description of an arbitrary computer program and an input,
    whether
    the program will finish running, or continue to run forever. Alan
    Turing proved
    in 1936 that a general algorithm to solve the halting problem for
    all possible
    program-input pairs cannot exist.

    For any program H that might determine if programs halt, a
    "pathological"
    program P, called with some input, can pass its own source and its
    input to
    H and then specifically do the opposite of what H predicts P will
    do. No H
    can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem



    #include <stdint.h>
    #define u32 uint32_t

    void P(u32 x)
    {
    if (H(x, x))
    HERE: goto HERE;
    return;
    }

    int main()
    {
    Output("Input_Halts = ", H((u32)P, (u32)P));
    }

    _P()
    [00001352](01) 55 push ebp
    [00001353](02) 8bec mov ebp,esp
    [00001355](03) 8b4508 mov eax,[ebp+08]
    [00001358](01) 50 push eax // push P
    [00001359](03) 8b4d08 mov ecx,[ebp+08]
    [0000135c](01) 51 push ecx // push P
    [0000135d](05) e840feffff call 000011a2 // call H
    [00001362](03) 83c408 add esp,+08
    [00001365](02) 85c0 test eax,eax
    [00001367](02) 7402 jz 0000136b
    [00001369](02) ebfe jmp 00001369
    [0000136b](01) 5d pop ebp
    [0000136c](01) c3 ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its input
    that it must emulate the first seven instructions of P. Because the
    seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.

    Because we can easily see that H(P,P)==0 is correct we can know that the otherwise "impossible" input to the halting problem proofs is correctly rejected as non-halting.



    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Freethinker@21:1/5 to olcott on Sun Jun 5 22:24:10 2022
    XPost: comp.lang.c, comp.lang.c++

    On 05.06.22 22:05, olcott wrote:
    On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:
    On Sat, 4 Jun 2022 11:14:19 -0500
    olcott <NoOne@NoWhere.com> wrote:
    On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:
    This post assumes that you already know my work, otherwise please read >>>>> the linked paper provided below. This work is based on the x86utm

    Thanks, but I need to go watch some paint dry. Maybe next time.



    Until the notion of truth itself is formalized research in artificial
    intelligence is hobbled.

    A correct refutation of the halting problem proofs also refutes the
    Tarski undefinability theorem by proxy, thus enabling the notion of
    truth to be formalized.

    This anchors the basis of Davidson's truth conditional semantics. This
    creates the roadmap for artificial intelligence with unlimited
    potential.

    Halting problem undecidability and infinitely nested simulation (V5)

    You sound like the output of a simple markov chain chat bot thats been
    fed
    some doctorate level CS papers.


    I posted to this group because I have boiled down a key computer science problem into ordinary software engineering in C/x86.

         In computability theory, the halting problem is the problem of determining,
         from a description of an arbitrary computer program and an input, whether
         the program will finish running, or continue to run forever. Alan Turing proved
         in 1936 that a general algorithm to solve the halting problem for all possible
         program-input pairs cannot exist.

         For any program H that might determine if programs halt, a "pathological"
         program P, called with some input, can pass its own source and its input to
         H and then specifically do the opposite of what H predicts P will do. No H
         can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem



    #include <stdint.h>
    #define u32 uint32_t

    void P(u32 x)
    {
      if (H(x, x))
        HERE: goto HERE;
      return;
    }

    int main()
    {
      Output("Input_Halts = ", H((u32)P, (u32)P));
    }

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax      // push P [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx      // push P [0000135d](05)  e840feffff      call 000011a2 // call H [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its input
    that it must emulate the first seven instructions of P. Because the
    seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.

    Because we can easily see that H(P,P)==0 is correct we can know that the otherwise "impossible" input to the halting problem proofs is correctly rejected as non-halting.



    What about the opposite: can you make a program that always correctly
    predicts that another program will halt? It doesn't seem to me that this
    case is included in what you did, but I must admit, computer science is
    not my major.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Freethinker on Sun Jun 5 15:31:09 2022
    XPost: comp.lang.c, comp.lang.c++

    On 6/5/2022 3:24 PM, Freethinker wrote:
    On 05.06.22 22:05, olcott wrote:
    On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:
    On Sat, 4 Jun 2022 11:14:19 -0500
    olcott <NoOne@NoWhere.com> wrote:
    On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
    On Fri, 3 Jun 2022 17:17:12 -0500
    olcott <NoOne@NoWhere.com> wrote:
    This post assumes that you already know my work, otherwise please
    read
    the linked paper provided below. This work is based on the x86utm

    Thanks, but I need to go watch some paint dry. Maybe next time.



    Until the notion of truth itself is formalized research in artificial
    intelligence is hobbled.

    A correct refutation of the halting problem proofs also refutes the
    Tarski undefinability theorem by proxy, thus enabling the notion of
    truth to be formalized.

    This anchors the basis of Davidson's truth conditional semantics. This >>>> creates the roadmap for artificial intelligence with unlimited
    potential.

    Halting problem undecidability and infinitely nested simulation (V5)

    You sound like the output of a simple markov chain chat bot thats
    been fed
    some doctorate level CS papers.


    I posted to this group because I have boiled down a key computer
    science problem into ordinary software engineering in C/x86.

          In computability theory, the halting problem is the problem of
    determining,
          from a description of an arbitrary computer program and an
    input, whether
          the program will finish running, or continue to run forever.
    Alan Turing proved
          in 1936 that a general algorithm to solve the halting problem
    for all possible
          program-input pairs cannot exist.

          For any program H that might determine if programs halt, a
    "pathological"
          program P, called with some input, can pass its own source and
    its input to
          H and then specifically do the opposite of what H predicts P
    will do. No H
          can exist that handles this case.
    https://en.wikipedia.org/wiki/Halting_problem



    #include <stdint.h>
    #define u32 uint32_t

    void P(u32 x)
    {
       if (H(x, x))
         HERE: goto HERE;
       return;
    }

    int main()
    {
       Output("Input_Halts = ", H((u32)P, (u32)P));
    }

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax      // push P >> [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx      // push P >> [0000135d](05)  e840feffff      call 000011a2 // call H
    [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]

    It is completely obvious that when H(P,P) correctly emulates its input
    that it must emulate the first seven instructions of P. Because the
    seventh instruction of P repeats this process we can know with
    complete certainty that the emulated P never reaches its final “ret”
    instruction, thus never halts.

    Because we can easily see that H(P,P)==0 is correct we can know that
    the otherwise "impossible" input to the halting problem proofs is
    correctly rejected as non-halting.



    What about the opposite: can you make a program that always correctly predicts that another program will halt? It doesn't seem to me that this
    case is included in what you did, but I must admit, computer science is
    not my major.

    The whole scope of my investigation was to simply correctly refute the conventional halting problem proofs, thus proving that a universal halt
    decider is possible. Actually making a a universal halt decider would
    take at least 1000 labor years.

    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben on Sun Jun 5 20:03:48 2022
    XPost: comp.theory, sci.logic

    On 6/5/2022 7:40 PM, Ben wrote:
    Jeff Barnett <jbb@notatt.com> writes:

    On 6/5/2022 5:59 PM, Mike Terry wrote:

    The question right now is what you would call a TM which evaluates
    the first 10 steps of a computation, and then does something else.
    What is it doing while evaluating those 10 steps?

    What would I call it? POOP! It just goes to show the accuracy and
    flexibility of Ben's acronym for any Peter-related concept.

    Credit where it's due... POOP is Richard's. Mine was not as good.


    That was the initial incorrect rebuttal that claimed the concept of a simulating halt decider is inherently invalid.

    When a simulating halt decider H correctly predicts that its complete simulation of its input finite string would never reach the final state
    of this machine description then H has correctly rejected this input as non-halting.

    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Sun Jun 5 21:14:34 2022
    XPost: comp.theory, sci.logic

    On 6/5/2022 8:59 PM, Richard Damon wrote:
    On 6/5/22 9:03 PM, olcott wrote:
    On 6/5/2022 7:40 PM, Ben wrote:
    Jeff Barnett <jbb@notatt.com> writes:

    On 6/5/2022 5:59 PM, Mike Terry wrote:

    The question right now is what you would call a TM which evaluates
    the first 10 steps of a computation, and then does something else.
    What is it doing while evaluating those 10 steps?

    What would I call it? POOP! It just goes to show the accuracy and
    flexibility of Ben's acronym for any Peter-related concept.

    Credit where it's due... POOP is Richard's.  Mine was not as good.


    That was the initial incorrect rebuttal that claimed the concept of a
    simulating halt decider is inherently invalid.

    When a simulating halt decider H correctly predicts that its complete
    simulation of its input finite string would never reach the final
    state of this machine description then H has correctly rejected this
    input as non-halting.


    No, its based on the fact that you are trying to define the "correct"
    answer for H to be something different than what the Halting Problem Requires.

    If that was true then one of these facts wold not be verified:
    (1) The relationship between H and P matches the pattern specified below:

    (2) H does correctly compute the mapping from the x86 machine code to
    its reject state on the basis

    For any program H that might determine if programs halt, a
    "pathological"
    program P, called with some input, can pass its own source and its
    input to
    H and then specifically do the opposite of what H predicts P will
    do. No H
    can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem

    void P(u32 x)
    {
    if (H(x, x))
    HERE: goto HERE;
    return;
    }

    int main()
    {
    Output("Input_Halts = ", H1((u32)P, (u32)P));
    }

    _P()
    [00001352](01) 55 push ebp
    [00001353](02) 8bec mov ebp,esp
    [00001355](03) 8b4508 mov eax,[ebp+08]
    [00001358](01) 50 push eax
    [00001359](03) 8b4d08 mov ecx,[ebp+08]
    [0000135c](01) 51 push ecx
    [0000135d](05) e840feffff call 000011a2 // call H
    [00001362](03) 83c408 add esp,+08
    [00001365](02) 85c0 test eax,eax
    [00001367](02) 7402 jz 0000136b
    [00001369](02) ebfe jmp 00001369
    [0000136b](01) 5d pop ebp
    [0000136c](01) c3 ret
    Size in bytes:(0027) [0000136c]



    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Mike Terry on Sun Jun 5 21:11:43 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/5/2022 8:58 PM, Mike Terry wrote:
    On 06/06/2022 01:24, Jeff Barnett wrote:
    On 6/5/2022 5:59 PM, Mike Terry wrote:
    <..snip..>>>
    Sure.
    The question right now is what you would call a TM which evaluates
    the first 10 steps of a computation, and then does something else.
    What is it doing while evaluating those 10 steps?

    What would I call it? POOP! It just goes to show the accuracy and
    flexibility of Ben's acronym for any Peter-related concept.


    But PO didn't invent the concept of (partially) simulating a computation
    in order to compute certain properties of that computation!  It's been around since Turing's days, and is very useful.

    Mike.

    That is true. I am apparently the first one that ever thought this
    through well enough so that machine descriptions matching the following
    pattern could be correctly determined to be non-halting:

    For any program H that might determine if programs halt, a
    "pathological"
    program P, called with some input, can pass its own source and its
    input to
    H and then specifically do the opposite of what H predicts P will
    do. No H
    can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem

    In that a partial simulation does correctly predict the behavior of a
    complete simulation it can be used to recognize infinite behavior patterns.

    --
    Copyright 2022 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sun Jun 5 21:59:21 2022
    XPost: comp.theory, sci.logic

    On 6/5/22 9:03 PM, olcott wrote:
    On 6/5/2022 7:40 PM, Ben wrote:
    Jeff Barnett <jbb@notatt.com> writes:

    On 6/5/2022 5:59 PM, Mike Terry wrote:

    The question right now is what you would call a TM which evaluates
    the first 10 steps of a computation, and then does something else.
    What is it doing while evaluating those 10 steps?

    What would I call it? POOP! It just goes to show the accuracy and
    flexibility of Ben's acronym for any Peter-related concept.

    Credit where it's due... POOP is Richard's.  Mine was not as good.


    That was the initial incorrect rebuttal that claimed the concept of a simulating halt decider is inherently invalid.

    When a simulating halt decider H correctly predicts that its complete simulation of its input finite string would never reach the final state
    of this machine description then H has correctly rejected this input as non-halting.


    No, its based on the fact that you are trying to define the "correct"
    answer for H to be something different than what the Halting Problem
    Requires.

    The DEFINITION of the Halting Problem is that

    H applied to <M> w needs to accept the input if M applied to w Halts and
    reject if M applied to w never halts.

    You want to change that to being based on "The correct simulation of its
    input by H reaching a final state", which is not equivalent.

    The key point is that by the classical definition of what a "correct simulation" would be that actually shows non-halting, a simulator that
    does that CAN'T answer non-halting, because the definition of a correct simulation of a non-halting machine is a non-halting simulation. (i.e.
    the behavior of a UTM).

    If your definition was based on "The correct simulation of its input by
    a UTM", then it would be ok, but since that isn't what you mean, your definition is different than the original, so it is your "Other Problem".

    It isn't that a simulating Halt Deicder is inherently invalid, but even
    a simulating halt decider needs to use the original definition of
    Halting, which means either looking that the behavior of the original
    machine, or the UTM simulation of the representation of it.

    Yes, this gives the decider an inherent problem, that it, like ALL Halt Deciders, needs to decide in finite time something that takes unbounded
    time to directly prove, but that is the nature of the Halting Problem,
    and what made it interesting. The hope initially was that there might be
    some "trick" that could be done to analyise the machine/input and be
    able to determine halting without needing to actually run the machine to
    the halting state (or a point it was clear that it would never halt).
    Turing showed that there could not be such a trick.

    You keep on erring because you start with assumptions that implicitly
    assume that a machine to give the answer is possible, when it isn't, and
    this leads you to a false conclusion and an inconsistent logic system.

    Many of your arguments actually boil down to, If I had a routine that
    solved the Halting Problem, I could wrap it up in code to transform the
    input into a somewhat different problem but with the same answer, and
    ask that routine about this new problem.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sun Jun 5 22:20:07 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/5/22 10:11 PM, olcott wrote:
    On 6/5/2022 8:58 PM, Mike Terry wrote:
    On 06/06/2022 01:24, Jeff Barnett wrote:
    On 6/5/2022 5:59 PM, Mike Terry wrote:
    <..snip..>>>
    Sure.
    The question right now is what you would call a TM which evaluates
    the first 10 steps of a computation, and then does something else.
    What is it doing while evaluating those 10 steps?

    What would I call it? POOP! It just goes to show the accuracy and
    flexibility of Ben's acronym for any Peter-related concept.


    But PO didn't invent the concept of (partially) simulating a
    computation in order to compute certain properties of that
    computation!  It's been around since Turing's days, and is very useful.

    Mike.

    That is true. I am apparently the first one that ever thought this
    through well enough so that machine descriptions matching the following pattern could be correctly determined to be non-halting:

         For any program H that might determine if programs halt, a "pathological"
         program P, called with some input, can pass its own source and its input to
         H and then specifically do the opposite of what H predicts P will do. No H
         can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem

    In that a partial simulation does correctly predict the behavior of a complete simulation it can be used to recognize infinite behavior patterns.


    Except that it doesn't since P(P) Halts if H(P,P) returns 0, which, by
    the DEFINITION of the requirements of the Halting Problem, H(P,P) needs
    to accept (return 1) if P(P) Halts, thus H was incorrect for a Halting
    Decider.

    You just try to use twisted words to try and describe what H actually
    did decide on to be close to words that could be used to descirbe the
    Halting Problem. But the slight difference is important, even if you
    don't think so.

    That just shows your level (or lack thereof) of knowledge of the field.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sun Jun 5 22:44:29 2022
    XPost: comp.theory, sci.logic

    On 6/5/22 10:14 PM, olcott wrote:
    On 6/5/2022 8:59 PM, Richard Damon wrote:
    On 6/5/22 9:03 PM, olcott wrote:
    On 6/5/2022 7:40 PM, Ben wrote:
    Jeff Barnett <jbb@notatt.com> writes:

    On 6/5/2022 5:59 PM, Mike Terry wrote:

    The question right now is what you would call a TM which evaluates >>>>>> the first 10 steps of a computation, and then does something else. >>>>>> What is it doing while evaluating those 10 steps?

    What would I call it? POOP! It just goes to show the accuracy and
    flexibility of Ben's acronym for any Peter-related concept.

    Credit where it's due... POOP is Richard's.  Mine was not as good.


    That was the initial incorrect rebuttal that claimed the concept of a
    simulating halt decider is inherently invalid.

    When a simulating halt decider H correctly predicts that its complete
    simulation of its input finite string would never reach the final
    state of this machine description then H has correctly rejected this
    input as non-halting.


    No, its based on the fact that you are trying to define the "correct"
    answer for H to be something different than what the Halting Problem
    Requires.

    If that was true then one of these facts wold not be verified:
    (1) The relationship between H and P matches the pattern specified below:

    (2) H does correctly compute the mapping from the x86 machine code to
    its reject state on the basis

    No definition of what "Correct computes the mapping"

    Remember the MAPPING that H needs to compute is that

    H(<M>, w) accepts if M(w) Halts, and rejects if M(w) doesn't halt.
    No mention of "simulations" here.

    Since P(P) is shown to Halt if H(P,P) returns 0 (reject), that mapping
    is NOT correctly computed.


         For any program H that might determine if programs halt, a "pathological" >      program P, called with some input, can pass its own source and its
    input to
         H and then specifically do the opposite of what H predicts P will do. No H
         can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem

    Since you H didn't handle the case, because H(P,P) results in a
    rejection, while P(P) Halts, you haven't show correctly computing of the Halting Map.


    void P(u32 x)
    {
      if (H(x, x))
        HERE: goto HERE;
      return;
    }

    int main()
    {
      Output("Input_Halts = ", H1((u32)P, (u32)P));
    }

    _P()
    [00001352](01)  55              push ebp
    [00001353](02)  8bec            mov ebp,esp
    [00001355](03)  8b4508          mov eax,[ebp+08]
    [00001358](01)  50              push eax
    [00001359](03)  8b4d08          mov ecx,[ebp+08]
    [0000135c](01)  51              push ecx
    [0000135d](05)  e840feffff      call 000011a2 // call H [00001362](03)  83c408          add esp,+08
    [00001365](02)  85c0            test eax,eax
    [00001367](02)  7402            jz 0000136b
    [00001369](02)  ebfe            jmp 00001369
    [0000136b](01)  5d              pop ebp
    [0000136c](01)  c3              ret
    Size in bytes:(0027) [0000136c]




    Not even your broken trace?

    Your slipping.

    FAIL.

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