• =?UTF-8?B?UmU6IMSkLnF4IOKfqMSk4p+pIOKfqMSk4p+pIOKKoiogxKQucW4gaXMg?= =?

    From olcott@21:1/5 to Ben Bacarisse on Wed Aug 11 09:28:31 2021
    XPost: comp.theory, comp.software-eng, sci.math.symbolic

    On 8/10/2021 9:26 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/10/2021 8:41 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/10/2021 7:42 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/7/2021 7:34 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/5/2021 9:36 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/5/2021 5:14 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
    The question is not: Does Ĥ halt on its input?
    Yes it is.

    The question is:
    Does the Ĥ specified by the first ⟨Ĥ⟩ halt on its input ⟨Ĥ⟩ ?
    The ansswer to this question is provably no!
    The question is: does Ĥ applied to ⟨Ĥ⟩ halt. It does: >>>>>>>>>
    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn THIS IS NOT A CONTRADICTION >>>>>>>>> Indeed. There is no contradiction. Just an Ĥ that does not meet Linz
    spec.

    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction.
    Because it is correct it meets the Linz spec.
    I find it startling that you think that, but then it seems you don't yet
    know what the key words mean:

    if M applied to wM does not halt
    means if the execution of the machine of the first ⟨Ĥ⟩ on its input of
    the seocond ⟨Ĥ⟩ does not halt then ⊢* Ĥ.qn
    No. Would you like to know "what M applied to wM does not halt" means? >>>>>>> Do you need help to see that "Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn" is clearly a case of "M
    applied to wM halts"?

    the Turing machine halting problem. Simply stated, the problem >>>>>> is: given the description of a Turing machine M and an input w, >>>>>> does M, when started in the initial configuration q0w, perform a >>>>>> computation that eventually halts? (Linz:1990:317).
    Yes. I was offering to help you understand the key words in that text. >>>>>
    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    You've missed off the key lines yet again. Is that deliberate? They >>>>> are the lines that show you are wrong so I am suspicious that you keep >>>>> omitting them.

    When Ĥ is applied to ⟨Ĥ⟩ the description of the Turing Machine and its
    input are specified as: ⟨Ĥ⟩ ⟨Ĥ⟩ for the embedded halt decider at Ĥ.qx.
    Ungrammatical.

    When Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn this is not a final state of the simulated
    input it is a final state of the executed Ĥ.
    Yes. You don't seem to know why that's wrong.

    What is your basis for believing that is wrong?
    Ah, a question about what I'm saying. I can help there. The basis is
    what Linz says about Ĥ. He says that (translating to your notation)
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
    should be the case "if Ĥ applied to ⟨Ĥ⟩ does not halt". But, as you can
    see, your Ĥ does halt when applied to ⟨Ĥ⟩ (qn is a halting or final >>> state). Your Ĥ is not doing what it should in this one crucial case.


    the Turing machine halting problem. Simply stated, the problem
    is: given the description of a Turing machine M and an input w,
    does M, when started in the initial configuration q0w, perform a
    computation that eventually halts? (Linz:1990:317).

    and so on. Same old stuff.


    When the challenge to support one's assertion with reasoning is simply
    ignored as you are ignoring it right now one can reasonably construe a deceptive intent.

    -- the Turing machine halting problem. Simply stated, the problem
    -- is: given the description of a Turing machine M and an input w,
    -- does M, when started in the initial configuration q0w, perform a
    -- computation that eventually halts? (Linz:1990:317).

    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H

    The input to H will be the description (encoded in some form) of M, say
    WM, as well as the input w. (Linz:1990:318)

    H.q0 WM w ⊢* H.qn
    if M applied to W does not halt.

    becomes

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
    if Ĥ applied to ⟨Ĥ⟩ does not halt.


    Pages of the Linz text to verify the above quotes in their full context: http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

    M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
    M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
    M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
    M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt

    When we know that M refers to the Turing machine specified by the first
    wM then when Ĥ transitions to its final state of Ĥ.qn there is no direct contradiction formed.

    Can you admit when you are wrong when you really are wrong?
    Can you admit when you are wrong when you really are wrong?
    Can you admit when you are wrong when you really are wrong?
    Can you admit when you are wrong when you really are wrong?

    if M applied to wM does not halt (see above for definition of M)
    means when the Turing machine of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    Ĥ.qx correctly transitions to its final state when the Ĥ.qx acts as a
    UTM and simulates ⟨Ĥ⟩ ⟨Ĥ⟩ and determines that this input never halts.

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

    I'm sorry my explanation did not help at all. I'm happy to answer any
    other questions you might have if you think it might help you understand
    what I (and Linz) are saying.



    --
    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 olcott on Wed Aug 11 09:58:25 2021
    XPost: comp.theory, comp.software-eng, sci.math.symbolic

    On 8/11/2021 9:28 AM, olcott wrote:
    On 8/10/2021 9:26 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/10/2021 8:41 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/10/2021 7:42 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/7/2021 7:34 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/5/2021 9:36 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/5/2021 5:14 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>
    The question is not: Does Ĥ halt on its input?
    Yes it is.

    The question is:
    Does the Ĥ specified by the first ⟨Ĥ⟩ halt on its input ⟨Ĥ⟩ ?
    The ansswer to this question is provably no!
    The question is: does Ĥ applied to ⟨Ĥ⟩ halt.  It does: >>>>>>>>>>
    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn  THIS IS NOT A CONTRADICTION >>>>>>>>>> Indeed.  There is no contradiction.  Just an Ĥ that does not >>>>>>>>>> meet Linz
    spec.

    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction.
    Because it is correct it meets the Linz spec.
    I find it startling that you think that, but then it seems you >>>>>>>> don't yet
    know what the key words mean:

    if M applied to wM does not halt
    means if the execution of the machine of the first ⟨Ĥ⟩ on its >>>>>>>>> input of
    the seocond ⟨Ĥ⟩ does not halt then ⊢* Ĥ.qn
    No.  Would you like to know "what M applied to wM does not halt" >>>>>>>> means?
    Do you need help to see that "Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn" is clearly a >>>>>>>> case of "M
    applied to wM halts"?

            the Turing machine halting problem. Simply stated, the >>>>>>> problem
            is: given the description of a Turing machine M and an >>>>>>> input w,
            does M, when started in the initial configuration q0w, >>>>>>> perform a
            computation that eventually halts? (Linz:1990:317). >>>>>> Yes.  I was offering to help you understand the key words in that >>>>>> text.

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    You've missed off the key lines yet again.  Is that deliberate?  They >>>>>> are the lines that show you are wrong so I am suspicious that you
    keep
    omitting them.

    When Ĥ is applied to ⟨Ĥ⟩ the description of the Turing Machine >>>>>>> and its
    input are specified as: ⟨Ĥ⟩ ⟨Ĥ⟩ for the embedded halt decider at
    Ĥ.qx.
    Ungrammatical.

    When Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn this is not a final state of the simulated
    input it is a final state of the executed Ĥ.
    Yes.  You don't seem to know why that's wrong.

    What is your basis for believing that is wrong?
    Ah, a question about what I'm saying.  I can help there.  The basis is >>>> what Linz says about Ĥ.  He says that (translating to your notation) >>>>     Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
    should be the case "if Ĥ applied to ⟨Ĥ⟩ does not halt".  But, as you
    can
    see, your Ĥ does halt when applied to ⟨Ĥ⟩ (qn is a halting or final >>>> state).  Your Ĥ is not doing what it should in this one crucial case. >>>>

        the Turing machine halting problem. Simply stated, the problem
        is: given the description of a Turing machine M and an input w,
        does M, when started in the initial configuration q0w, perform a
        computation that eventually halts? (Linz:1990:317).

    and so on.  Same old stuff.


    When the challenge to support one's assertion with reasoning is simply ignored as you are ignoring it right now one can reasonably construe a deceptive intent.

    -- the Turing machine halting problem. Simply stated, the problem
    -- is: given the description of a Turing machine M and an input w,
    -- does M, when started in the initial configuration q0w, perform a
    -- computation that eventually halts? (Linz:1990:317).

    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H

    The input to H will be the description (encoded in some form) of M, say
    WM, as well as the input w. (Linz:1990:318)

    H.q0 WM w ⊢* H.qn
    if M applied to W does not halt.

      becomes

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
    if Ĥ applied to ⟨Ĥ⟩ does not halt.


    Pages of the Linz text to verify the above quotes in their full context: http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

    M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
    M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
    M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
    M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt

    When we know that M refers to the Turing machine specified by the first
    wM then when Ĥ transitions to its final state of Ĥ.qn there is no direct contradiction formed.

    Can you admit when you are wrong when you really are wrong?
    Can you admit when you are wrong when you really are wrong?
    Can you admit when you are wrong when you really are wrong?
    Can you admit when you are wrong when you really are wrong?

    if M applied to wM does not halt (see above for definition of M)
    means when the Turing machine of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt.

    Ĥ.q0 ⟨Ĥ⟩  ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    Ĥ.qx correctly transitions to its final state when the Ĥ.qx acts as a
    UTM and simulates ⟨Ĥ⟩ ⟨Ĥ⟩ and determines that this input never halts.

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


    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    if M applied to wM halts, and // M refers to the TM of the first wM parameter to Ĥ.qx

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt // M refers to the TM of the first wM parameter to Ĥ.qx



    --
    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 Ben Bacarisse on Wed Aug 11 14:53:11 2021
    XPost: comp.theory, comp.software-eng, sci.math.symbolic

    On 8/11/2021 11:10 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/11/2021 9:28 AM, olcott wrote:

    Subject: Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction. [ Is Ben a Liar or simply woefully ignorant? ]

    This is a scumbag move. It's also cowardly and disingenuous --
    pretending to be coy about your scumbag opinions. I'll leave it
    unedited as it says everything readers need to know about your
    character.

    When the challenge to support one's assertion with reasoning is simply
    ignored as you are ignoring it right now one can reasonably construe
    a deceptive intent.

    A scumbag could construe it that way. Reasonable people could come to
    all sorts of other conclusions.

    H.q0 WM w ⊢* H.qn
    if M applied to W does not halt.
    if M applied to MW does not halt.

    (typo corrected)

      becomes
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
    if Ĥ applied to ⟨Ĥ⟩ does not halt.

    Yes. After a lot a pressing (and I mean lots, over several years!) you eventually admitted that H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ does indeed transition to H.qn.
    You also keep telling us that Ĥ applied to ⟨Ĥ⟩ halts. That's why your H
    (and its associated Ĥ) are wrong but for some reason you can't see this.

    You will plainly state that H rejects the string "⟨Ĥ⟩ ⟨Ĥ⟩" which it should do if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt. And you will, time and time again, show us exactly how Ĥ applied to ⟨Ĥ⟩ halts.

    This should be the end of the matter, but apparently your stating facts
    that show that H and Ĥ are wrong does not mean you know that H and Ĥ are wrong. I don't think I know any way to make progress on this.

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt
    ...
    if M applied to wM does not halt (see above for definition of
    M) means when the Turing machine of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt.

    Of course. We all know that. Unless you are pulling a fast one. "the Turing machine of ⟨Ĥ⟩" is just Ĥ. Is there a reason you are not simply saying "when Ĥ applied to ⟨Ĥ⟩ does not halt"?

    Ĥ.q0 ⟨Ĥ⟩  ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    Ĥ.qx correctly transitions to its final state when the Ĥ.qx acts as a
    UTM and simulates ⟨Ĥ⟩ ⟨Ĥ⟩ and determines that this input never halts.

    Yes, we know the ruse: the computation would not halt if it were not the computation that it is. You've been trying to pull off this trick ever
    since the infamous "it wouldn't halt if line 15 was commented out"
    admission. Your Ĥ, however, not being a UTM, has the property that

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    when it should not. Ĥ.q0 ⟨Ĥ⟩ should eventually transition to qn only "if Ĥ applied to ⟨Ĥ⟩ does not halt" (or, as you rather suspiciously write "if the Turing machine of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt"). But
    you've told us, time and time again, that Ĥ applied to ⟨Ĥ⟩ halts. You keep showing us the summary description of it's configuration sequence.
    You keep showing us the final state it transitions to. It's so obvious, someone would need about 16 years misunderstanding Turing machines to
    avoid seeing it.

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    if M applied to wM halts, and // M refers to the TM of the first wM
    parameter to Ĥ.qx

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt // M refers to the TM of the first wM
    parameter to Ĥ.qx

    The case you care about has M = Ĥ and wM = ⟨Ĥ⟩ as you've written it out above.


    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    if M applied to wM halts, and

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn // see highlighted portion of Linz text to confirm:
    if M applied to wM does not halt // M refers to the TM of the first
    wM parameter to Ĥ.qx

    Turing machine Ĥ is applied to its input ⟨Ĥ⟩. It copies this input such that this input and the copy of this input become the first and second parameters to the simulating halt decider at Ĥ.qx. When Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
    decides that the simulation of its first parameter on the input of its
    second parameter never halt it correctly transitions to its own final
    state of Ĥ.qn.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Wed Aug 11 19:26:14 2021
    XPost: comp.theory, comp.software-eng, sci.math.symbolic

    On 8/11/2021 7:01 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/11/2021 11:10 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/11/2021 9:28 AM, olcott wrote:
    Subject: Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no
    contradiction. [ Is Ben a Liar or simply woefully ignorant? ]

    This is a scumbag move. It's also cowardly and disingenuous --
    pretending to be coy about your scumbag opinions. I'll leave it
    unedited as it says everything readers need to know about your
    character.

    This is still a scumbag move.

    When the challenge to support one's assertion with reasoning is simply >>>>> ignored as you are ignoring it right now one can reasonably construe >>>>> a deceptive intent.
    A scumbag could construe it that way. Reasonable people could come to
    all sorts of other conclusions.

    H.q0 WM w ⊢* H.qn
    if M applied to W does not halt.
    if M applied to MW does not halt.
    (typo corrected)

      becomes
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
    if Ĥ applied to ⟨Ĥ⟩ does not halt.

    Yes. After a lot a pressing (and I mean lots, over several years!) you
    eventually admitted that H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ does indeed transition to H.qn.
    You also keep telling us that Ĥ applied to ⟨Ĥ⟩ halts. That's why your H
    (and its associated Ĥ) are wrong but for some reason you can't see this. >>>
    You will plainly state that H rejects the string "⟨Ĥ⟩ ⟨Ĥ⟩" which it
    should do if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt. And you >>> will, time and time again, show us exactly how Ĥ applied to ⟨Ĥ⟩ halts.

    This should be the end of the matter, but apparently your stating facts
    that show that H and Ĥ are wrong does not mean you know that H and Ĥ are >>> wrong. I don't think I know any way to make progress on this.

    You just read past this explanation of why your H and Ĥ are wrong and
    you decided that you understood everything I'd said, did you? And you
    also decided that nothing in these three paragraphs needs to be
    challenged?


    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    if M applied to wM halts, and

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt

    // M refers to the TM of the first wM parameter to Ĥ.qx

    Now that you accept that the above is true we can move on to the next
    point. My proof must proceed exactly one point at a time an cannot
    possibly move to the next point until the current point is fully accepted.

    That you believe that the fact that Ĥ applied to ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts nullifies the fact that Ĥ.qx wM wM does correctly decide that its input never halts is the next point.

    It is easier to discuss this with the H(P,P) model of the exact same
    thing because with the H(P,P) model we can examine every single detail.

    _P()
    [00000d02](01) 55 push ebp
    [00000d03](02) 8bec mov ebp,esp
    [00000d05](03) 8b4508 mov eax,[ebp+08]
    [00000d08](01) 50 push eax // push 2nd Param
    [00000d09](03) 8b4d08 mov ecx,[ebp+08]
    [00000d0c](01) 51 push ecx // push 1st Param
    [00000d0d](05) e870feffff call 00000b82 // call H
    [00000d12](03) 83c408 add esp,+08
    [00000d15](02) 85c0 test eax,eax
    [00000d17](02) 7402 jz 00000d1b
    [00000d19](02) ebfe jmp 00000d19
    [00000d1b](01) 5d pop ebp
    [00000d1c](01) c3 ret
    Size in bytes:(0027) [00000d1c]

    ...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H

    Begin Local Halt Decider Simulation at Machine Address:d02 ...[00000d02][002118f1][002118f5] 55 push ebp ...[00000d03][002118f1][002118f5] 8bec mov ebp,esp ...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08] ...[00000d08][002118ed][00000d02] 50 push eax // push P ...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08] ...[00000d0c][002118e9][00000d02] 51 push ecx // push P ...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H

    ...[00000d02][0025c319][0025c31d] 55 push ebp ...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp ...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08] ...[00000d08][0025c315][00000d02] 50 push eax // push P ...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08] ...[00000d0c][0025c311][00000d02] 51 push ecx // push P ...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    It is very obvious to people that know the x86 language very well that
    while H acts as a pure simulator of P(P) that P cannot possibly stop
    running.

    The same thing applies to the infinite cycle from Ĥ.qx to Ĥ.q0 while the simulating halt decider at Ĥ.qx acts as a UTM.

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    if M applied to wM halts, and

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt

    // M refers to the TM of the first wM parameter to Ĥ.qx


    There's not much more I can add if you do indeed understand and accept
    these remarks of mine. But, as I keep saying, I'm happy to answer any questions you may have about my explanation.



    --
    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 Ben Bacarisse on Wed Aug 11 21:14:00 2021
    XPost: comp.theory, comp.software-eng, sci.math.symbolic

    On 8/11/2021 8:35 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/11/2021 11:10 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/11/2021 9:28 AM, olcott wrote:

    H.q0 WM w ⊢* H.qn
    if M applied to W does not halt.
    if M applied to MW does not halt.
    (typo corrected)

      becomes
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
    if Ĥ applied to ⟨Ĥ⟩ does not halt.
    Yes. After a lot a pressing (and I mean lots, over several years!) you
    eventually admitted that H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ does indeed transition to H.qn.
    You also keep telling us that Ĥ applied to ⟨Ĥ⟩ halts. That's why your H
    (and its associated Ĥ) are wrong but for some reason you can't see this. >>> You will plainly state that H rejects the string "⟨Ĥ⟩ ⟨Ĥ⟩" which it
    should do if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt. And you >>> will, time and time again, show us exactly how Ĥ applied to ⟨Ĥ⟩ halts.
    This should be the end of the matter, but apparently your stating facts
    that show that H and Ĥ are wrong does not mean you know that H and Ĥ are >>> wrong. I don't think I know any way to make progress on this.

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt
    ...
    if M applied to wM does not halt (see above for definition of
    M) means when the Turing machine of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt.
    Of course. We all know that. Unless you are pulling a fast one. "the
    Turing machine of ⟨Ĥ⟩" is just Ĥ. Is there a reason you are not simply
    saying "when Ĥ applied to ⟨Ĥ⟩ does not halt"?

    I didn't expect an answer. You may be reserving this phrase as a
    get-out clause for later, so saying what you mean too early will block
    that escape route.

    Ĥ.q0 ⟨Ĥ⟩  ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    Ĥ.qx correctly transitions to its final state when the Ĥ.qx acts as a >>>>> UTM and simulates ⟨Ĥ⟩ ⟨Ĥ⟩ and determines that this input never halts.
    Yes, we know the ruse: the computation would not halt if it were not the >>> computation that it is. You've been trying to pull off this trick ever
    since the infamous "it wouldn't halt if line 15 was commented out"
    admission. Your Ĥ, however, not being a UTM, has the property that
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    when it should not. Ĥ.q0 ⟨Ĥ⟩ should eventually transition to qn only >>> "if Ĥ applied to ⟨Ĥ⟩ does not halt" (or, as you rather suspiciously >>> write "if the Turing machine of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt").

    We can see that the above never halts.

    We can see that it halts. It's right there in a fact that has been undisputed for months:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn


    The above Ĥ halts only because Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
    input never halts.

    the Turing machine halting problem. Simply stated, the problem
    is: given the description of a Turing machine M and an input w,
    does M, when started in the initial configuration q0w, perform a
    computation that eventually halts? (Linz:1990:317).

    Thus the halting problem is solved for this input because the halting
    problem only applies to inputs. It does not apply to computations that
    are not inputs.


    --
    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 Ben Bacarisse on Wed Aug 11 21:03:11 2021
    XPost: comp.theory, comp.software-eng, sci.math.symbolic

    On 8/11/2021 8:20 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/11/2021 6:04 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 8/11/2021 10:04 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    I went point by point. If I am actually incorrect then you can go
    point by point and point out each individual error step by step.
    You fail at the first hurdle. You can't hope to persuade anyone that an >>>>> add function with add(2, 3) == 9 is operating as specified simply by >>>>> detailing, step by step, exactly how you implement the wrong behaviour. >>>>> In your case, it's simply that Ĥ.q0 ⟨Ĥ⟩ transitions to Ĥ.qn (via Ĥ.qx
    ⟨Ĥ⟩ ⟨Ĥ⟩ as you pointlessly keep insisting) when Linz says it should not.
    Your add function is entirely correct in that is does exactly what you >>>>> intend it to do. As far as I am concerned there is no significant error >>>>> in how you arrive at add(2, 3) == 9. The problem is that Linz says your >>>>> code should add numbers and not do whatever it is your code does with >>>>> 100% correctness. Do you follow?

    Of course
    everyone knows that this is impossible if I am totally correct.
    Then stop wasting time and try to publish! You'll need lots of time to >>>>> explain away why every editor simply laughs at the paper.

    H.q0 WM w ⊢* Ĥ.qn
    becomes
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
    Yes, we all know that. It's exactly why your Ĥ does not meet Linz's >>>>> specification (for this case -- you don't claim to have a halt decider). >>>>>
    Can you admit when you are wrong when you really are wrong?
    Yes. I am wrong all the time. In this case I'm having trouble working >>>>> out how I could be clearer about your Ĥ. Maybe if you didn't keep
    removing the key text from Linz's explanations it might sink in?


    Pages of the Linz text to verify the above quotes in their full context: >>>> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H >>> I see you are in "paste the same text" again mode. If you think I can
    help in any way, do let me know.

    I just noticed that you acknowledged that M refers to the TM
    represented by the first input parameter to Ĥ.qx wM wM

    Did I? Oh dear. It's garbage. Where did I "acknowledge" it? I'd like
    to go back and point out that it's mathematical junk.

    so we can move to the next point:

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    if M applied to wM halts, and

    This is just a metaphorical math poem. You've taken a mathematical
    statement and substituted for only some on the occurrences of a
    variable. That is a schoolboy error.


    That seems to be a very stupid thing to say when it only clarifies and
    corrects Linz.

    Maybe you confused agreement with "can't be bothered to go of on a
    tangent about a math poem". I certainly let many meaningless things you write slip by unremarked upon. There are not enough hours in the day to point out all your mistakes.

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn // see highlighted portion of Linz text >> to confirm:
    if M applied to wM does not halt // M refers to the TM of the first wM
    parameter to Ĥ.qx

    Linz requires that

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.


    Sure and the Ĥ being referred to is the one that the first param to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ specifies.

    Unlike your garbage, this makes sense because all occurrences of M and
    the derived wM have now been substituted for actual values -- your Ĥ and
    its encoding.

    Here is the overview of what I am claiming:
    Turing machine Ĥ is applied to its input ⟨Ĥ⟩.

    Ĥ.q0 ⟨Ĥ⟩

    It copies this input such that this input and the copy of this input
    become the first and second parameters to the simulating halt decider
    at Ĥ.qx.

    ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩

    When Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ decides that the simulation of its first parameter
    on the input of its second parameter never halt it correctly
    transitions to its own final state of Ĥ.qn.

    ⊢* Ĥ.qn

    None of which (other than your poor use of technical terms) has been in
    doubt for months.


    You sure acted like M only referred to the first Ĥ shown below:
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.

    It is easy to see that when the halt decider at Ĥ.qx is a simulating
    halt decider that there is an infinite cycle from Ĥ.qx to Ĥ.q0 that
    prevents the input from every reaching its final state.

    If Ĥ were not written as you have chosen to write it -- if it were
    instead a pure simulator, then

    ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ∞


    This: Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    specifies an infinite cycle from Ĥ.qx to Ĥ.q0 while the simulating halt decider at Ĥ.qx acts as a UTM.

    would be the case. Mathematicians would avoid this messy language and
    the possibility of confusion by not re-using the name Ĥ for both your partial decider and one based on pure simulation.


    Since it is the very same machine in two different modes of operation
    this seems really stupid.

    This <is> the same Ĥ that Linz specifies with the extra detail of how
    this wildcard state transition works: ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    Also, you are wrong about the cycles of states, but that's because you
    have no clue how a TM would simulate another TM.

    No one ever investigates this because their paper on the subject would
    be millions of pages long if it included a full listing of the source
    code. If we add the single feature of random access memory TMs would be 100,000-fold less tedious.

    It's a rabbit hole we
    shouldn't go down, because (a) I don't think you could ever understand
    how a UTM really works, and (b) it's irrelevant since I agree that there would be infinite execution if Ĥ were not as it is but were, instead, a
    pure simulator.


    Great. This is a big breakthrough.

    When we define halting as reaching a final state

    Ĥ applied to ⟨Ĥ⟩ halts. The computation reaches the final state Ĥ.qn.


    Yes. The halting problem is not about programs that halt. It is about
    inputs to a halt decider. The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

    so that we can unequivocally divide computations that complete from
    those that are aborted,

    So this is today's equivocation. TM computations either halt or they
    don't halt. None of them "abort".


    I am concurrently perfecting my understanding of the technical terms via
    Linz. A TM can also be said to halt if there is no transition out of the current state. Ultimately I only need a clear and unequivocal way to
    divide computations that reach their natural conclusion from ones that
    have had their simulation aborted.

    then we know that the input to Ĥ.qx never
    halts, thus making its halt status decison correct.

    Garbled. Inputs don't halt or not halt. Your Ĥ does not meet Linz's
    spec because Ĥ applied to ⟨Ĥ⟩ halts when it should not. You don't get to say it does because it halts in what you think of as special way.


    That is like saying because we know the liar paradox: "this sentence is
    not true" is not true then it must be true.

    My purpose of creating the x86utm operating system was so that every
    single detail of the halting problem counter-examples can be completely examined.

    It is perfectly analogous in every way to the Linz Ĥ.
    We can see that int main() { P(P); } halts and that the input to H(P,P)
    cannot possibly halt. That is a lot like finding a cat that barks.

    No one besides me has ever bothered to examine every single detail of
    H(P,P) to see that its input really cannot possibly halt.

    They are all so egotistically caught up in their own opinion that the
    fact that int main() { P(P); } halts proves that H(P,P)==0 must be
    incorrect.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Thu Aug 12 15:36:00 2021
    XPost: comp.theory, comp.software-eng, sci.math.symbolic

    On 8/12/2021 3:00 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    if M applied to wM halts, and

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt

    // M refers to the TM of the first wM parameter to Ĥ.qx

    Now that you accept that the above is true...

    I don't. It's a garbled formula arising from a silly error on your
    part. I'd like to know where (you think) I said I accept this nonsense
    so I can correct any such impression.

    ... we can move on to the next point. My proof must proceed exactly
    one point at a time an cannot possibly move to the next point until
    the current point is fully accepted.

    It would be simpler if we worked though the reasons you are wrong
    because there are fewer steps.

    You've stated that

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    and you accept (at least you keep quoting) that Linz requires that this should be the case only if Ĥ applied to ⟨Ĥ⟩ does not halt. QED.

    That you believe that the fact that Ĥ applied to ⟨Ĥ⟩ transitions to
    its final state of Ĥ.qn and halts nullifies the fact that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
    does correctly decide that its input never halts is the next point.

    ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation as shown a few
    lines above. That Ĥ applied to ⟨Ĥ⟩ halts does not "nullify" anything, it's just wrong as clearly stated by Linz.


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation.

    Ĥ is a TM that halts only because
    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input never halts.

    When you examine this in its x86utm equivalent of H(P,P) there are no
    loopholes that can slip through the cracks because every detail is
    explicitly encoded in the x86 language.

    When we examine this as Ĥ applied to ⟨Ĥ⟩ there are millions of pages of Turing machine code that cannot be explicitly specified.

    None-the-less the key element of all this is the fact that if we assume
    that the simulating halt decider at Ĥ.qx is simply a UTM then it becomes
    quite obvious that we have an infinite cycle from Ĥ.qx to Ĥ.q0.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    If we know that we have an infinite cycle then this knowledge all by
    itself proves that the simulating halt decider at Ĥ.qx must abort the simulation of its input which proves that this 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)
  • From olcott@21:1/5 to Malcolm McLean on Fri Aug 13 08:30:33 2021
    XPost: comp.theory, comp.software-eng, sci.math.symbolic

    On 8/13/2021 3:58 AM, Malcolm McLean wrote:
    On Thursday, 12 August 2021 at 16:50:19 UTC+1, olcott wrote:
    On 8/12/2021 10:40 AM, Malcolm McLean wrote:
    On Thursday, 12 August 2021 at 13:24:46 UTC+1, olcott wrote:
    On 8/12/2021 3:36 AM, Malcolm McLean wrote:
    On Thursday, 12 August 2021 at 06:11:30 UTC+1, Jeff Barnett wrote:
    On 8/11/2021 5:40 PM, olcott wrote:
    On 8/11/2021 6:32 PM, Jeff Barnett wrote:
    On 8/11/2021 5:04 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
    PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H

    I see you are in "paste the same text" again mode. If you think I can >>>>>>>>> help in any way, do let me know.

    That's not nice. Aren't you afraid that he'll develop carpal tunnel >>>>>>>> syndrome? That along with all of his other deficiencies will surely do >>>>>>>> him in. Perhaps we can invent shortcuts a la LaTeX macros and font >>>>>>>> switches to help him cut down the strain. He wont be insulted and will >>>>>>>> take to it as a pig to mud. Just think, he'll have yet another >>>>>>>> notation to misuse and abuse.

    Ben finally acknowledged the point that I was making:

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
    if M applied to wM halts, and

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt

    // M refers to the TM of the first wM parameter to Ĥ.qx

    My proof requires a whole inference chain that cannot proceed to the >>>>>>> next point until the current point is accepted as correct.
    In addition to carpal tunnel, you are delusional. I get the vague
    impression reading the above that you are having a schizoid episode. >>>>>> There is a complete and total discount between what others say to you >>>>>> and your replies. I suggest you cut out some of the examples you like >>>>>> best and show them to your therapist. You do have one, don't you? It may >>>>>> lead to better, more effective treatment. We are all hoping you get >>>>>> better but schizoid episodes are hard to suppress. I assume meds have >>>>>> been prescribed for your condition. Are you taking them? Or are you >>>>>> refusing medical help just as you refuse to allow Ben to heal your >>>>>> ignorance. A little trust in your betters will go a long way towards >>>>>> recovery and a cure. Start now before it's to late. God speed to you. >>>>>> -
    YOu might be right, but I think it's just frustration. His execution trace shows
    what appears to be an infinitely recursive process aborted, and everyone is
    just ignoring that and focusing on the other reality that his H does not >>>>> return the result that matches the behaviour of the input when run independently.

    The attempt to use formal math notation when he doesn't understand it >>>>> doesn't help. That can create the impression of mental incoherence, but in fact
    it's not that.

    Despite a mass of posting, we still don't have a good idea how H works. >>>> _P()
    [00000d02](01) 55 push ebp
    [00000d03](02) 8bec mov ebp,esp
    [00000d05](03) 8b4508 mov eax,[ebp+08]
    [00000d08](01) 50 push eax // push 2nd Param
    [00000d09](03) 8b4d08 mov ecx,[ebp+08]
    [00000d0c](01) 51 push ecx // push 1st Param
    [00000d0d](05) e870feffff call 00000b82 // call H
    [00000d12](03) 83c408 add esp,+08
    [00000d15](02) 85c0 test eax,eax
    [00000d17](02) 7402 jz 00000d1b
    [00000d19](02) ebfe jmp 00000d19
    [00000d1b](01) 5d pop ebp
    [00000d1c](01) c3 ret
    Size in bytes:(0027) [00000d1c]
    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========= =============
    ...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H

    Begin Local Halt Decider Simulation at Machine Address:d02
    ...[00000d02][002118f1][002118f5] 55 push ebp
    ...[00000d03][002118f1][002118f5] 8bec mov ebp,esp
    ...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
    ...[00000d08][002118ed][00000d02] 50 push eax // push P
    ...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
    ...[00000d0c][002118e9][00000d02] 51 push ecx // push P
    ...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H

    ...[00000d02][0025c319][0025c31d] 55 push ebp
    ...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
    ...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
    ...[00000d08][0025c315][00000d02] 50 push eax // push P
    ...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
    ...[00000d0c][0025c311][00000d02] 51 push ecx // push P
    ...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped
    If this means that you are telling me that:
    (1) You know the x86 language very well.

    (2) Can't begin to understand why P would be stuck in infinitely nested >>>> simulation while H acts as a pure simulator?

    OK, so let's start.
    There's a line which says "Begin Local Halt Decider Simulation at Machine >>> Address:d02". Is that part of the execution trace, or is it a commented added
    by hand? If it is part of the execution trace, why doesn't this line appear >>> before the second line with the label 0d02?
    The halt decider automatically writes this when it begins the simulation
    that its halt analysis is based on.

    OK, so why don't we get a second "Begin Local Halt Decider ..." line output?

    Begin Local Halt Decider Simulation at Machine Address:d02 ...[00000d02][002118f1][002118f5] 55 push ebp ...[00000d03][002118f1][002118f5] 8bec mov ebp,esp ...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08] ...[00000d08][002118ed][00000d02] 50 push eax // push P ...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08] ...[00000d0c][002118e9][00000d02] 51 push ecx // push P ...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H ...[00000d02][0025c319][0025c31d] 55 push ebp ...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp ...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08] ...[00000d08][0025c315][00000d02] 50 push eax // push P ...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08] ...[00000d0c][0025c311][00000d02] 51 push ecx // push P ...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    The simulation of the input begins and continues until it ends.


    I would say that you must be a liar.

    I have a PhD. PhD holder attach a very high value to honesty, in particular >>> with respect to their subjects. But also more generally. I always draw attention
    if I'm given too much change at the pub, for example, not becaue I'm better >>> than other people, but because I'm a doctor, and a doctor can't be seen to >>> take money that doesn't belong to him.

    So do (1) and (2) apply to you?

    That was a demand for an apology, but you are too focused on your own interests to be sensitive to what other people are trying to communicate to you.


    I still can't tell whether you are telling the truth or not because you
    have not yet committed to the actual truth and rejected the falsehood.
    If (1) and (2) do apply to you then you would be a liar.

    The point that I am trying to make here is so damn simple that everyone
    should have agreed to it in less than a week. It has been many months.

    There is no freaking code in the body of P that can possibly escape
    infinitely nested simulation while H remains a pure simulator. If you as
    much as refrain from agreeing to that (and know the x86 language very
    well) then you would be a liar.

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