• Re: Experts would agree that my reviewers are incorrect [ Why are you s

    From olcott@21:1/5 to Richard Damon on Fri Jun 3 16:08:34 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/2/2022 9:41 PM, Richard Damon wrote:
    On 6/2/22 7:45 PM, olcott wrote:
    On 6/2/2022 6:38 PM, Mr Flibble wrote:
    On Thu, 2 Jun 2022 15:47:22 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/2/2022 1:12 PM, Andy Walker wrote:
    On 02/06/2022 17:21, Ben wrote:
    [...]  We know simulation can't be
    used to decide halting, and we know that there are only two ways a >>>>>> decider that tries to do so can be wrong.  Both come up every time >>>>>> this is taught to a class of programmers.  (I've never taught it
    to a class of mathematicians but I suspect the discussion would be >>>>>> very different.)

          My first thought was "no, it's the same", but on reflexion, >>>>> and AFAIR, our mathematicians simply accepted what I told them,
    which is essentially what
    is at

          http://www.cuboid.me.uk/anw/G12FCO/lect17.html

    [second half, but see esp the last paragraph] and

          http://www.cuboid.me.uk/anw/G12FCO/lect18.html


    For these cases, we can turn to our second weapon -- emulation. We
    want to know whether a program halts, so we try it. If it halts, then
    we know the answer. If it doesn't halt, then `it must be in a loop',
    so we monitor its state and `detect the loop'. Sadly, although this
    is in one sense correct, it is a false dichotomy. 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.

    It is not considered correctly.
    (a) the program has halted
    (b) the program is still running
    (c) the program matched an infinite behavior pattern

           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

    Any competent software engineer can verify that H(P,P)==0
    for the above behavior pattern. (The entire research scope)
    As detailed 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



    The proofs you are attempting to refute do not contain the infinite
    behaviour pattern you describe;

    The correctly simulated input to a simulating halt decider never
    reaches the final instruction of this simulated input thus is
    unequivocally non-halting.

    You keep on saying that, but it isn't actually true for the PROPER
    definition of "correct simulation", that being, the simulation of the
    input by a UTM equiavlent. (or an x86 processor for your x86 code).

    What you want to call "correct simulation" is the partial simulation by
    a particular H, but partial simulation are NEVER "correct" because they
    are, by definitin=on, INCOMPLETE.
    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 other words you keep saying the same cockamamy bullshit that it is
    utterly impossible to correctly determine what a complete simulation
    would be from a partial simulation.

    This is the exactly same numbskull idea that it is utterly impossible to determine that a loop is infinite until after waiting forever to see if
    it stops running. *Why are you such a jackass?*

    --
    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 Mr Flibble@21:1/5 to olcott on Fri Jun 3 22:47:06 2022
    XPost: comp.theory, sci.logic, sci.math

    On Fri, 3 Jun 2022 16:08:34 -0500
    olcott <polcott2@gmail.com> wrote:

    On 6/2/2022 9:41 PM, Richard Damon wrote:
    On 6/2/22 7:45 PM, olcott wrote:
    On 6/2/2022 6:38 PM, Mr Flibble wrote:
    On Thu, 2 Jun 2022 15:47:22 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/2/2022 1:12 PM, Andy Walker wrote:
    On 02/06/2022 17:21, Ben wrote:
    [...] We know simulation can't be
    used to decide halting, and we know that there are only two
    ways a decider that tries to do so can be wrong. Both come up
    every time this is taught to a class of programmers. (I've
    never taught it to a class of mathematicians but I suspect the
    discussion would be very different.)

    My first thought was "no, it's the same", but on
    reflexion, and AFAIR, our mathematicians simply accepted what I
    told them, which is essentially what
    is at

    http://www.cuboid.me.uk/anw/G12FCO/lect17.html

    [second half, but see esp the last paragraph] and

    http://www.cuboid.me.uk/anw/G12FCO/lect18.html


    For these cases, we can turn to our second weapon -- emulation.
    We want to know whether a program halts, so we try it. If it
    halts, then we know the answer. If it doesn't halt, then `it
    must be in a loop', so we monitor its state and `detect the
    loop'. Sadly, although this is in one sense correct, it is a
    false dichotomy. 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.

    It is not considered correctly.
    (a) the program has halted
    (b) the program is still running
    (c) the program matched an infinite behavior pattern

    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

    Any competent software engineer can verify that H(P,P)==0
    for the above behavior pattern. (The entire research scope)
    As detailed 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



    The proofs you are attempting to refute do not contain the
    infinite behaviour pattern you describe;

    The correctly simulated input to a simulating halt decider never
    reaches the final instruction of this simulated input thus is
    unequivocally non-halting.

    You keep on saying that, but it isn't actually true for the PROPER definition of "correct simulation", that being, the simulation of
    the input by a UTM equiavlent. (or an x86 processor for your x86
    code).

    What you want to call "correct simulation" is the partial
    simulation by a particular H, but partial simulation are NEVER
    "correct" because they are, by definitin=on, INCOMPLETE.
    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 other words you keep saying the same cockamamy bullshit that it is utterly impossible to correctly determine what a complete simulation
    would be from a partial simulation.

    This is the exactly same numbskull idea that it is utterly impossible
    to determine that a loop is infinite until after waiting forever to
    see if it stops running. *Why are you such a jackass?*

    Your "infinite loop" only starts if an infinite recursion is detected
    however the proofs you are attempting to refute contain no such
    infinite recursion so your "infinite loop" is irrelevant.

    /Flibble

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

    On 6/3/22 5:08 PM, olcott wrote:
    On 6/2/2022 9:41 PM, Richard Damon wrote:
    On 6/2/22 7:45 PM, olcott wrote:
    On 6/2/2022 6:38 PM, Mr Flibble wrote:
    On Thu, 2 Jun 2022 15:47:22 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/2/2022 1:12 PM, Andy Walker wrote:
    On 02/06/2022 17:21, Ben wrote:
    [...]  We know simulation can't be
    used to decide halting, and we know that there are only two ways a >>>>>>> decider that tries to do so can be wrong.  Both come up every time >>>>>>> this is taught to a class of programmers.  (I've never taught it >>>>>>> to a class of mathematicians but I suspect the discussion would be >>>>>>> very different.)

          My first thought was "no, it's the same", but on reflexion, >>>>>> and AFAIR, our mathematicians simply accepted what I told them,
    which is essentially what
    is at

          http://www.cuboid.me.uk/anw/G12FCO/lect17.html

    [second half, but see esp the last paragraph] and

          http://www.cuboid.me.uk/anw/G12FCO/lect18.html


    For these cases, we can turn to our second weapon -- emulation. We
    want to know whether a program halts, so we try it. If it halts, then >>>>> we know the answer. If it doesn't halt, then `it must be in a loop', >>>>> so we monitor its state and `detect the loop'. Sadly, although this
    is in one sense correct, it is a false dichotomy. 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.

    It is not considered correctly.
    (a) the program has halted
    (b) the program is still running
    (c) the program matched an infinite behavior pattern

           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

    Any competent software engineer can verify that H(P,P)==0
    for the above behavior pattern. (The entire research scope)
    As detailed 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



    The proofs you are attempting to refute do not contain the infinite
    behaviour pattern you describe;

    The correctly simulated input to a simulating halt decider never
    reaches the final instruction of this simulated input thus is
    unequivocally non-halting.

    You keep on saying that, but it isn't actually true for the PROPER
    definition of "correct simulation", that being, the simulation of the
    input by a UTM equiavlent. (or an x86 processor for your x86 code).

    What you want to call "correct simulation" is the partial simulation
    by a particular H, but partial simulation are NEVER "correct" because
    they are, by definitin=on, INCOMPLETE.
    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 other words you keep saying the same cockamamy bullshit that it is
    utterly impossible to correctly determine what a complete simulation
    would be from a partial simulation.

    This is the exactly same numbskull idea that it is utterly impossible to determine that a loop is infinite until after waiting forever to see if
    it stops running.  *Why are you such a jackass?*


    No, that isn't what I said.

    I said that H can not generate a correct simulation of that input,
    because it will generate only a partial simulation of it, and that by definition is NOT correct.

    Note, sometimes you can derive a correct halting answer from a partial simulation, because the partial simulation actually does show a pattern
    that correctly detects the non-halting behavior.

    The fact that you have made this exact same mistake several times just
    shows that you seem to have a learning disability and are unable to
    learn from your mistakes, so you are doomed to keep repeating them.

    Maybe if you would actually read what people say, you might be able to undertand what is happening.

    It might be that you are just too ignorant of the terminology that even
    these simple statements are beyond you understanding, or maybe the
    problem is you just don't actually care what is actually true, but just
    want to "steamroller" your false ideas.

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

    On 6/3/2022 5:31 PM, Richard Damon wrote:
    On 6/3/22 5:08 PM, olcott wrote:
    On 6/2/2022 9:41 PM, Richard Damon wrote:
    On 6/2/22 7:45 PM, olcott wrote:
    On 6/2/2022 6:38 PM, Mr Flibble wrote:
    On Thu, 2 Jun 2022 15:47:22 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/2/2022 1:12 PM, Andy Walker wrote:
    On 02/06/2022 17:21, Ben wrote:
    [...]  We know simulation can't be
    used to decide halting, and we know that there are only two ways a >>>>>>>> decider that tries to do so can be wrong.  Both come up every time >>>>>>>> this is taught to a class of programmers.  (I've never taught it >>>>>>>> to a class of mathematicians but I suspect the discussion would be >>>>>>>> very different.)

          My first thought was "no, it's the same", but on reflexion, >>>>>>> and AFAIR, our mathematicians simply accepted what I told them,
    which is essentially what
    is at

          http://www.cuboid.me.uk/anw/G12FCO/lect17.html

    [second half, but see esp the last paragraph] and

          http://www.cuboid.me.uk/anw/G12FCO/lect18.html


    For these cases, we can turn to our second weapon -- emulation. We >>>>>> want to know whether a program halts, so we try it. If it halts, then >>>>>> we know the answer. If it doesn't halt, then `it must be in a loop', >>>>>> so we monitor its state and `detect the loop'. Sadly, although this >>>>>> is in one sense correct, it is a false dichotomy. 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. >>>>>>
    It is not considered correctly.
    (a) the program has halted
    (b) the program is still running
    (c) the program matched an infinite behavior pattern

           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

    Any competent software engineer can verify that H(P,P)==0
    for the above behavior pattern. (The entire research scope)
    As detailed 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



    The proofs you are attempting to refute do not contain the infinite
    behaviour pattern you describe;

    The correctly simulated input to a simulating halt decider never
    reaches the final instruction of this simulated input thus is
    unequivocally non-halting.

    You keep on saying that, but it isn't actually true for the PROPER
    definition of "correct simulation", that being, the simulation of the
    input by a UTM equiavlent. (or an x86 processor for your x86 code).

    What you want to call "correct simulation" is the partial simulation
    by a particular H, but partial simulation are NEVER "correct" because
    they are, by definitin=on, INCOMPLETE.
    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 other words you keep saying the same cockamamy bullshit that it is
    utterly impossible to correctly determine what a complete simulation
    would be from a partial simulation.

    This is the exactly same numbskull idea that it is utterly impossible
    to determine that a loop is infinite until after waiting forever to
    see if it stops running.  *Why are you such a jackass?*


    No, that isn't what I said.

    I said that H can not generate a correct simulation of that input,
    because it will generate only a partial simulation of it, and that by definition is NOT correct.
    BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
    PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

    BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
    PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

    BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
    PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

    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:55:30 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/3/22 6:40 PM, olcott wrote:
    On 6/3/2022 5:31 PM, Richard Damon wrote:
    On 6/3/22 5:08 PM, olcott wrote:
    On 6/2/2022 9:41 PM, Richard Damon wrote:
    On 6/2/22 7:45 PM, olcott wrote:
    On 6/2/2022 6:38 PM, Mr Flibble wrote:
    On Thu, 2 Jun 2022 15:47:22 -0500
    olcott <NoOne@NoWhere.com> wrote:

    On 6/2/2022 1:12 PM, Andy Walker wrote:
    On 02/06/2022 17:21, Ben wrote:
    [...]  We know simulation can't be
    used to decide halting, and we know that there are only two ways a >>>>>>>>> decider that tries to do so can be wrong.  Both come up every time >>>>>>>>> this is taught to a class of programmers.  (I've never taught it >>>>>>>>> to a class of mathematicians but I suspect the discussion would be >>>>>>>>> very different.)

          My first thought was "no, it's the same", but on reflexion, >>>>>>>> and AFAIR, our mathematicians simply accepted what I told them, >>>>>>>> which is essentially what
    is at

          http://www.cuboid.me.uk/anw/G12FCO/lect17.html

    [second half, but see esp the last paragraph] and

          http://www.cuboid.me.uk/anw/G12FCO/lect18.html


    For these cases, we can turn to our second weapon -- emulation. We >>>>>>> want to know whether a program halts, so we try it. If it halts, >>>>>>> then
    we know the answer. If it doesn't halt, then `it must be in a loop', >>>>>>> so we monitor its state and `detect the loop'. Sadly, although this >>>>>>> is in one sense correct, it is a false dichotomy. 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. >>>>>>>
    It is not considered correctly.
    (a) the program has halted
    (b) the program is still running
    (c) the program matched an infinite behavior pattern

           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

    Any competent software engineer can verify that H(P,P)==0
    for the above behavior pattern. (The entire research scope)
    As detailed 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



    The proofs you are attempting to refute do not contain the infinite >>>>>> behaviour pattern you describe;

    The correctly simulated input to a simulating halt decider never
    reaches the final instruction of this simulated input thus is
    unequivocally non-halting.

    You keep on saying that, but it isn't actually true for the PROPER
    definition of "correct simulation", that being, the simulation of
    the input by a UTM equiavlent. (or an x86 processor for your x86 code). >>>>
    What you want to call "correct simulation" is the partial simulation
    by a particular H, but partial simulation are NEVER "correct"
    because they are, by definitin=on, INCOMPLETE.
    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 other words you keep saying the same cockamamy bullshit that it is
    utterly impossible to correctly determine what a complete simulation
    would be from a partial simulation.

    This is the exactly same numbskull idea that it is utterly impossible
    to determine that a loop is infinite until after waiting forever to
    see if it stops running.  *Why are you such a jackass?*


    No, that isn't what I said.

    I said that H can not generate a correct simulation of that input,
    because it will generate only a partial simulation of it, and that by
    definition is NOT correct.
    BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
    PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

    BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
    PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

    BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
    PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

    Except it doesn't in the case of H(P,P) because H uses FAULTY logic to
    decide to abort.


    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).

    Yes, there IS an infinite behavior pattern in Infinite_Loop to prove
    that it will not halt.


    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.

    Except, as been pointed out, the only way for H(P,P) to actually correct emulate its input is to NEVER abort (BY THE DEFINITION OF CORRECT
    SIMULATION).


    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, as I just explained elsewhere, this is a FALSE statement.

    After the 7th instruction must be the 8th in the program, that is the instruction at 000011a2, or, at a bare minimum, list that the nexrt
    round is a trace of the CONDITIONALLY SIMULATION of the H being simulated.

    This BREAKS the pattern you are thinking of using.

    Your repeating the LIE just makes you a pathological liar, or a complete
    idiot.




    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)