• Concise refutation of halting problem proofs V4

    From olcott@21:1/5 to All on Sun Nov 7 07:25:06 2021
    XPost: comp.theory, sci.logic, sci.math

    After many reviews no one has pointed out any error in this claim:
    There is no possible simulating halt decider H such that the correct
    pure simulation of the input to H(P,P) ever reaches the final
    instruction of P.

    I suspect that the reason for this is that no one here has a sufficient understanding of the x86 language.

    // Simplified Linz Ĥ (Linz:1990:319)
    // Strachey(1965) CPL translated to C
    void P(u32 x)
    {
    if (H(x, x))
    HERE: goto HERE;
    }

    _P()
    [00000c36](01) 55 push ebp
    [00000c37](02) 8bec mov ebp,esp
    [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
    [00000c3c](01) 50 push eax
    [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
    [00000c40](01) 51 push ecx
    [00000c41](05) e820fdffff call 00000966 // call H
    [00000c46](03) 83c408 add esp,+08
    [00000c49](02) 85c0 test eax,eax
    [00000c4b](02) 7402 jz 00000c4f
    [00000c4d](02) ebfe jmp 00000c4d
    [00000c4f](01) 5d pop ebp
    [00000c50](01) c3 ret
    Size in bytes:(0027) [00000c50]

    When each instruction of the x86 source code of P is simulated in the
    exact same sequence that it is specified in the above source code then
    we know that this aspect of the pure simulation the input to H(P,P) is perfectly correct.

    We also know that when H is a pure simulator of its input that the
    seventh line of the correct pure simulation execution trace shown below
    would result in another identical sequence of seven lines.

    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========= ============= [00000c36][002117ca][002117ce] 55 push ebp [00000c37][002117ca][002117ce] 8bec mov ebp,esp [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08] [00000c3c][002117c6][00000c36] 50 push eax // push P [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08] [00000c40][002117c2][00000c36] 51 push ecx // push P [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

    We don't need to see the 350 pages of the simulation of H to know that
    if this H performs a pure simulation of its input that the above seven
    lines will be repeated in the subsequent nested simulation.

    Every simulating halt decider H has two possible actions:
    (a) Allow the infinitely nested simulation of its input to continue (and
    thus fail to be a decider).

    (b) Recognized the infinitely nested simulation of its input and abort
    this simulation of this input.

    Anyone having the mandatory prerequisite knowledge of the x86 language
    can see that there is no possible simulating halt decider H such that
    the correct pure simulation of the input to H(P,P) ever reaches its
    final state.

    After many reviews no one has pointed out any error in this claim:
    There is no possible simulating halt decider H such that the correct
    pure simulation of the input to H(P,P) ever reaches the final
    instruction of P.




    Strachey, C 1965. An impossible program The Computer Journal, Volume 7,
    Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313

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

    Halting problem undecidability and infinitely nested simulation
    May 2021 PL Olcott

    https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation




    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein


    If you had the mandatory prerequisite knowledge of the x86 language
    (which apparently no one here does) then you would see that

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Mr Flibble on Sun Nov 7 18:25:49 2021
    XPost: comp.theory, sci.logic, sci.math

    On 11/7/2021 3:59 PM, Mr Flibble wrote:
    On Sun, 07 Nov 2021 20:52:58 +0000
    Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

    Mr Flibble <flibble@reddwarf.jmc> writes:

    On Sun, 07 Nov 2021 13:57:26 +0000
    Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

    olcott <NoOne@NoWhere.com> writes:

    After many reviews no one has pointed out any error in this
    claim: There is no possible simulating halt decider H such that
    the correct pure simulation of the input to H(P,P) ever reaches
    the final instruction of P.

    As you know, there are no halt deciders

    Not true. As long as the decider can recognize pathological self
    reference and has infinite resources it can decide if a program
    halts.

    That's not what a halt decider is.

    Sure it is.

    /Flibble


    ...As long as the decider can... decide if a program halts:
    Then we know it must be a halt decider for this program.

    Because they are so highly motivated to disagree here are the key points
    that no one else yet understands:

    (A) If the simulated input of H(P,P) never halts then it is correct for
    H to report that its simulated input never halts.

    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Sun Nov 7 20:00:10 2021
    XPost: comp.theory, sci.logic, sci.math

    On 11/7/2021 7:24 PM, André G. Isaak wrote:
    On 2021-11-07 18:17, olcott wrote:
    On 11/7/2021 6:39 PM, André G. Isaak wrote:
    On 2021-11-07 17:25, olcott wrote:
    On 11/7/2021 3:59 PM, Mr Flibble wrote:
    On Sun, 07 Nov 2021 20:52:58 +0000
    Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

    Mr Flibble <flibble@reddwarf.jmc> writes:

    On Sun, 07 Nov 2021 13:57:26 +0000
    Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
    olcott <NoOne@NoWhere.com> writes:
    After many reviews no one has pointed out any error in this
    claim: There is no possible simulating halt decider H such that >>>>>>>>> the correct pure simulation of the input to H(P,P) ever reaches >>>>>>>>> the final instruction of P.

    As you know, there are no halt deciders

    Not true. As long as the decider can recognize pathological self >>>>>>> reference and has infinite resources it can decide if a program
    halts.

    That's not what a halt decider is.

    Sure it is.

    /Flibble


    ...As long as the decider can... decide if a program halts:
    Then we know it must be a halt decider for this program.

    Because they are so highly motivated to disagree here are the key
    points that no one else yet understands:

    (A) If the simulated input of H(P,P) never halts then it is correct
    for H to report that its simulated input never halts.

    Not when you claim that the simulation can differ from the actual
    execution.

    So you are saying that sometimes a cat is not a cat.

    I never mentioned cats. I am saying that a "simulation" which differs
    from the actual execution is not actually a simulation at all.

    Arguing with semantic tautologies makes you look stupid.

    I'm not arguing with a semantic tautology. I'm arguing against your
    rather ridiculous claims.

    You are saying that when the correct pure simulation of the input to
    H(P,P) never halts it is incorrect for H to report that the simulation
    of its input never halts which is the same thing as saying that it is
    incorrect to say that a cat is a cat.



    (B) Because of the one-way dependency relationship between the
         executed P and the simulation of itself that it invokes: H(P,P) >>>>      [ P only halts because H(P,P) returns 0 ]
         the executed P has different behavior than its simulated P.

    Putting aside your strange use of the term 'simulate', a halt decider

    So again you are saying that a cat is not a cat except that you are
    saying that a correct simulation is not a correct simulation.

    If it doesn't behave identically to the actual computation then it is
    not a correct simulation.

    André



    If there is a correct pure simulation of the input to H1(P,P) that does
    behave the same as the direct execution of its input and there is
    another verifiably correct pure simulation H(P,P) that does not behave
    the same way as the above two then we have conclusive proof that this
    latter computation is entirely different than the first two.

    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.



    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Sun Nov 7 19:17:58 2021
    XPost: comp.theory, sci.logic, sci.math

    On 11/7/2021 6:39 PM, André G. Isaak wrote:
    On 2021-11-07 17:25, olcott wrote:
    On 11/7/2021 3:59 PM, Mr Flibble wrote:
    On Sun, 07 Nov 2021 20:52:58 +0000
    Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

    Mr Flibble <flibble@reddwarf.jmc> writes:

    On Sun, 07 Nov 2021 13:57:26 +0000
    Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
    olcott <NoOne@NoWhere.com> writes:
    After many reviews no one has pointed out any error in this
    claim: There is no possible simulating halt decider H such that
    the correct pure simulation of the input to H(P,P) ever reaches
    the final instruction of P.

    As you know, there are no halt deciders

    Not true. As long as the decider can recognize pathological self
    reference and has infinite resources it can decide if a program
    halts.

    That's not what a halt decider is.

    Sure it is.

    /Flibble


    ...As long as the decider can... decide if a program halts:
    Then we know it must be a halt decider for this program.

    Because they are so highly motivated to disagree here are the key
    points that no one else yet understands:

    (A) If the simulated input of H(P,P) never halts then it is correct
    for H to report that its simulated input never halts.

    Not when you claim that the simulation can differ from the actual
    execution.

    So you are saying that sometimes a cat is not a cat.
    Arguing with semantic tautologies makes you look stupid.


    (B) Because of the one-way dependency relationship between the
         executed P and the simulation of itself that it invokes: H(P,P)
         [ P only halts because H(P,P) returns 0 ]
         the executed P has different behavior than its simulated P.

    Putting aside your strange use of the term 'simulate', a halt decider

    So again you are saying that a cat is not a cat except that you are
    saying that a correct simulation is not a correct simulation.

    When each instruction of the x86 source code of P is simulated in the
    exact same sequence that it is specified in the above source code then
    we know that this aspect of the pure simulation the input to H(P,P) is perfectly correct.

    We also know that when H is a pure simulator of its input that the
    seventh line of the correct pure simulation execution trace shown below
    would result in another identical sequence of seven lines.

    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========= ============= [00000c36][002117ca][002117ce] 55 push ebp [00000c37][002117ca][002117ce] 8bec mov ebp,esp [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08] [00000c3c][002117c6][00000c36] 50 push eax // push P [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08] [00000c40][002117c2][00000c36] 51 push ecx // push P [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)


    must accurately describe the behaviour of "executed P". That's the


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.


    (B) Because of the one-way dependency relationship between the
    executed P and the simulation of itself that it invokes: H(P,P)
    [ P only halts because H(P,P) returns 0 ]
    the executed P has different behavior than its simulated P.

    Because there is no such dependency relationship in H1(P,P) the pure
    simulation of its input corresponds to the direct execution of this same
    input.




    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Mon Nov 8 13:52:53 2021
    XPost: comp.theory, sci.logic, sci.math

    On 11/8/2021 10:32 AM, André G. Isaak wrote:
    On 2021-11-08 08:26, olcott wrote:
    On 11/7/2021 11:51 PM, André G. Isaak wrote:
    On 2021-11-07 22:00, olcott wrote:
    On 11/7/2021 10:46 PM, André G. Isaak wrote:
    On 2021-11-07 20:19, olcott wrote:

    Yet you cannot point to a single error in any of the details below >>>>>> because there are no errors in any of the details below.

    I don't *need* to point out any errors in the below.

    If is it not simulated correctly then at least one of the simulated
    instructions is not simulated correctly. If all of the simulated
    instructions are simulated correctly then the simulation is correct.

    If it were being simulated correctly, the simulation would have the
    exact same behaviour as P(P). It does not. It is therefore not being
    simulated correctly. BY DEFINITION.

    And your trace don't show anything being simulated. If it did, the
    actual simulator code would be part of the trace.


    Even if I was merely simulating it in my head and writing it down
    using cut-and-paste the fact that

    Each instruction of the x86 source code of P is simulated in the exact
    same sequence that it is specified in the above source code then we
    know that this aspect of the pure simulation the input to H(P,P) is
    perfectly correct.

    We know that P(P) halts. Therefore you are not correctly simulating the instruction which causes it to halt. Therefore you are not "correctly" simulating it.


    We verify that H(P,P) does perform a correct pure simulation the first
    seven instructions of its input on the basis of the one-to-one mapping
    of the first seven instructions of the x86 source-code of P to the first
    seven steps of the listed simulation of P.

    Since the seventh instruction of P simply calls H(P,P) again we know
    that these same seven steps would be repeated in this nested simulation.

    From these 14 correctly simulated steps we can see that the nested
    simulation never stops unless H aborts it.

    Because we know that the correctly simulated input to H(P,P) never
    reaches its final state whether or not H(P,P) aborts the simulation of
    its input we know that H(P,P)==0 is correct for every simulating halt
    decider H.



    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Mon Nov 8 16:54:20 2021
    XPost: comp.theory, sci.logic, sci.math

    On 11/8/2021 2:47 PM, André G. Isaak wrote:
    On 2021-11-08 12:52, olcott wrote:
    On 11/8/2021 10:32 AM, André G. Isaak wrote:
    On 2021-11-08 08:26, olcott wrote:
    On 11/7/2021 11:51 PM, André G. Isaak wrote:
    On 2021-11-07 22:00, olcott wrote:
    On 11/7/2021 10:46 PM, André G. Isaak wrote:
    On 2021-11-07 20:19, olcott wrote:

    Yet you cannot point to a single error in any of the details
    below because there are no errors in any of the details below.

    I don't *need* to point out any errors in the below.

    If is it not simulated correctly then at least one of the
    simulated instructions is not simulated correctly. If all of the
    simulated instructions are simulated correctly then the simulation >>>>>> is correct.

    If it were being simulated correctly, the simulation would have the
    exact same behaviour as P(P). It does not. It is therefore not
    being simulated correctly. BY DEFINITION.

    And your trace don't show anything being simulated. If it did, the
    actual simulator code would be part of the trace.


    Even if I was merely simulating it in my head and writing it down
    using cut-and-paste the fact that

    Each instruction of the x86 source code of P is simulated in the
    exact same sequence that it is specified in the above source code
    then we know that this aspect of the pure simulation the input to
    H(P,P) is perfectly correct.

    We know that P(P) halts. Therefore you are not correctly simulating
    the instruction which causes it to halt. Therefore you are not
    "correctly" simulating it.


    You do not address the critical point: P(P) halts.

    I have addressed it many times and you make sure to always ignore the
    fact that P(P) and H(P,P) are proven to be entirely different
    computations by the fact of the one-way dependency of P(P) on the return
    value of its invocation of H(P,P).



    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Mr Flibble on Tue Nov 9 12:39:06 2021
    XPost: comp.theory, sci.logic, sci.math

    On 11/9/2021 12:26 PM, Mr Flibble wrote:
    On Mon, 8 Nov 2021 07:33:44 -0500
    Richard Damon <Richard@Damon-Family.org> wrote:

    On 11/8/21 12:00 AM, olcott wrote:
    On 11/7/2021 10:46 PM, André G. Isaak wrote:
    On 2021-11-07 20:19, olcott wrote:
    On 11/7/2021 8:57 PM, André G. Isaak wrote:
    On 2021-11-07 19:00, olcott wrote:
    On 11/7/2021 7:24 PM, André G. Isaak wrote:
    On 2021-11-07 18:17, olcott wrote:
    On 11/7/2021 6:39 PM, André G. Isaak wrote:
    On 2021-11-07 17:25, olcott wrote:
    On 11/7/2021 3:59 PM, Mr Flibble wrote:
    On Sun, 07 Nov 2021 20:52:58 +0000
    Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

    Mr Flibble <flibble@reddwarf.jmc> writes:

    On Sun, 07 Nov 2021 13:57:26 +0000
    Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
    olcott <NoOne@NoWhere.com> writes:
    After many reviews no one has pointed out any error in >>>>>>>>>>>>>>>> this claim: There is no possible simulating halt >>>>>>>>>>>>>>>> decider H such that
    the correct pure simulation of the input to H(P,P) >>>>>>>>>>>>>>>> ever reaches
    the final instruction of P.

    As you know, there are no halt deciders

    Not true. As long as the decider can recognize
    pathological self
    reference and has infinite resources it can decide if a >>>>>>>>>>>>>> program halts.

    That's not what a halt decider is.

    Sure it is.

    /Flibble


    ...As long as the decider can... decide if a program halts: >>>>>>>>>>> Then we know it must be a halt decider for this program. >>>>>>>>>>>
    Because they are so highly motivated to disagree here are >>>>>>>>>>> the key points that no one else yet understands:

    (A) If the simulated input of H(P,P) never halts then it is >>>>>>>>>>> correct for H to report that its simulated input never
    halts.

    Not when you claim that the simulation can differ from the >>>>>>>>>> actual execution.

    So you are saying that sometimes a cat is not a cat.

    I never mentioned cats. I am saying that a "simulation" which
    differs from the actual execution is not actually a simulation >>>>>>>> at all.

    Arguing with semantic tautologies makes you look stupid.

    I'm not arguing with a semantic tautology. I'm arguing against >>>>>>>> your rather ridiculous claims.

    You are saying that when the correct pure simulation of the
    input to H(P,P) never halts it is incorrect for H to report
    that the simulation of its input never halts which is the same
    thing as saying that it is incorrect to say that a cat is a
    cat.

    No. I am saying that H(P, P) does not perform a 'correct pure
    simulation' of its input. A halt decider must accurately
    describe the behaviour of the *actual* computation P(P).

    Yet you cannot point to a single error in any of the details
    below because there are no errors in any of the details below.

    I don't *need* to point out any errors in the below.

    If is it not simulated correctly then at least one of the simulated
    instructions is not simulated correctly. If all of the simulated
    instructions are simulated correctly then the simulation is
    correct.

    The Call 966 is not simulated correctly.

    That has been pointed out before and you have ignored it, so you LIE
    when you say that all the instructions are simulated correctly.

    You put a deciteful disclaimer that limits the correctness to only
    the 'simulated instructions' but that is just a dishonest dodge as a
    pure simulation must simulate ALL the instructions it come to, not
    just some select set.

    It isn't even an equivalent simulation, as the substitution of
    substituion of the code being simulated for the simulation of the
    simulator is a valid transform only for an unconditional simulator,
    and thus by doing so you are building into your precondition set that
    H will NEVER abort its simulation. When you then decide to have H
    abort its simulation you violate your conditions.

    That is like making a transform on an equation that is based on the
    fact that x > x+1, because there is no such x, just as there is no H
    that both never aborts it simulation and also aborts its simulation.

    This equivalence IS valid for just one case, the case when H actually
    doesn't ever abort its simulation. In this case you proof does work,
    and you do show that the P based on that H is non-halting, but
    unfortunately for you, you also prove that in that case, H never
    actually gives that answer, so this H isn't correct either.

    A lot of you 'logic' is just a smoke screen to try and decive the
    reader to think that it is ok for the H that aborts its simulation to
    be used to decide on the P based on the H that doesn't. It does get
    that case right, but it isn't the case you need to show, you need to
    show that an H can get the H^/P based on itself correctly.

    You seem to regularly like to reuse notation for different cases,
    which appears to just be again part of your pattern to deceive.Even
    you switch from H^ to P is an example of this.


    The fact that P(P) halts whereas your simulation does not is
    sufficient to know that it is not an accurate simulation. An
    accurate simulation behaves *identically* to the thing being
    simulated. Yours does not. That's a simple matter of definition.

    That no one has pointed out the specific error in your trace is
    because the trace omits the relevant details

    It does not omit any relevant details.

    WRONG. LIAR.


    (i.e. the point at which it decides to abort or not to abort). And
    the trace is meaningless because the result of the test eax, eax
    instruction depends on that omitted code.

    André


    Do you understand that if H(P,P) aborts the simulation of its input
    that its input never reaches its final state and thus never halts?


    WRONG. The fact that H(P,P) aborts ITS Simulation of its input does
    not affect what the PURE SIMULATION of that input would do.

    UTM(P,P) Halts whenever H(P,P) == 0, that is a simple provable fact.

    You just show you total IGNORANCE by your claim.

    H, if it returns 0, is NOT a PURE SIMULATOR, you should know it,
    either you are a LIAR or an IDIOT.

    Which is it.

    (Attacking the person): This fallacy occurs when, instead of addressing someone's argument or position, you irrelevantly attack the person or
    some aspect of the person who is making the argument.

    Olcott's halt decider either decides if a program halts or does not
    halt or it throws an exception if pathological self reference occurs;
    it is thus a valid halt decider -- the third result of exception is
    perfectly valid result as it only occurs if you are DELIBERATELY trying
    to defeat the decider but I still contend the decider needs to be a
    black box to legitimately enable this behavior.

    /Flibble

    --
    This message is a troll.


    To refute the claim that the direct execution of P(P) halts thus its
    simulation is incorrect H(P,P) directly executes its input instead of simulating it. The result is that the infinitely nested simulation
    becomes infinite recursion. In no case does the following directly
    executed P ever reach its final state of c50.

    // call void P(I);
    int H(u32 P, u32 I)
    {
    if (!Halts(P,I)
    return 0;
    ((void(*)(int))P)(I);
    return 1;
    }

    int main()
    {
    H((u32)P, (u32)P);
    }

    What people here fail to realize is that the behavior of any machine
    that is not an input to H is out-of-scope for any simulating halt
    decider H. If the correct pure simulation of the input to H(P,P) never
    halts then it is always correct for every H to report that its input
    never halts.

    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

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