• Re: Refuting the Peter Linz Halting Problem Proof V6 [ simplified ]

    From olcott@21:1/5 to Dennis Bush on Fri Apr 1 07:08:56 2022
    XPost: comp.theory, sci.math, sci.logic

    On 4/1/2022 6:36 AM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote:
    On 3/31/2022 10:16 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote:
    On 3/31/2022 9:34 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott wrote:
    On 3/31/2022 9:23 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott wrote:
    On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO BE REJECTED: >>>>>>>>>>>>
    Linz and everyone here believes that deciders must base their decision
    on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ over-ruling the
    actual behavior specified by the actual finite string actual input.
    Here's that question you would not answer without equivocating, even
    after my asking it more than 12 times in a row. André also asked many,
    many times and got no answer.
    What string must be passed to H so that H can tell us whether or not Ĥ
    applied to ⟨Ĥ⟩ halts? Do you reject even the idea that a halt decider
    could tell us whether a particular TM does or does not halt when given
    some particular input? Isn't that what the theorem is about? (The >>>>>>>>>>> answer is, of course, yes.)

    DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE DIFFERENT BEHAVIOR. >>>>>>>>>>
    The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be computationally
    equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ yet not the
    same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.

    Failure to answer number one (or 13 if you count my previous attempts).
    Here's the question in case you missed it:

    What string must be passed to H so that H can tell us whether or not Ĥ
    applied to ⟨Ĥ⟩ halts?
    I worked out many of the details of this, and can see why you believe it
    is an important point, I will not begin to discuss this
    until after you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the basis that
    the correctly simulated input to embedded_H would never reach its own >>>>>>>> final state in any finite number of simulated steps.

    embedded_Ha, and therefore Ha, is not correct to reject <Ha^><Ha^> because it quits its simulation after n steps which is too soon. When this same input is given to simulating halt decider Hb which simulates for n+k steps, the input does reach
    its final state after n+k steps and Hb accepts <Ha^><Ha^>. Therefore Ha, and subsequently embedded_Ha, does *not* correctly simulate its input.
    I will simply say that I am ignoring another strawman error.

    Just saying "strawman" isn't good enough.
    I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated semantics any
    change in notation or semantics is off topic.

    I am sure that you can make a million halt deciders that don't work they >>>> are all strawman.

    So you can't explain why Hb is wrong, and have therefore implicitly admitted it is correct.

    So what are you doing to do now that your proof has been refuted?
    That you can make up some screwy thing that doesn't work says nothing
    about my proof. If you were talking about my proof then you have to use
    my notation, my semantics and find an error in that.

    How exactly is it that Hb "doesn't work"?

    When you talk about H / embedded_H that "correctly" reports non-halting for H^, you're talking about an H that aborts it's simulation. That's Ha / embedded_Ha and Ha^ is built from that. What I said still stands. So state why Hb is wrong or admit
    failure.


    On 3/31/2022 9:23 PM, Dennis Bush wrote:
    embedded_Ha, and therefore Ha, is not correct to reject <Ha^><Ha^>
    because it quits its simulation after n steps which is too soon. When
    this same input is given to simulating halt decider Hb which simulates
    for n+k steps, the input does reach its final state after n+k steps and
    Hb accepts <Ha^><Ha^>. Therefore Ha, and subsequently embedded_Ha, does
    *not* correctly simulate its input.

    It is like I talk about driving my car to show that my car can be driven
    so you drive a car into a tree to show that a car cannot be driven.

    Here are the simplified notational conventions and semantics:
    (Any attempt to diverge from the specified semantics will be construed
    as the strawman error and marked as ignored)

    We will just call the halt decider H:
    H ⟨p⟩ ⟨i⟩ ⊢* H.qy iff UTM simulated ⟨p⟩ ⟨i⟩ reaches its final state
    H ⟨p⟩ ⟨i⟩ ⊢* H.qn iff UTM simulated ⟨p⟩ ⟨i⟩ would never reach its
    final state

    Simplified Ĥ directly calls H --- infinite loop has been removed.
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn




    --
    Copyright 2022 Pete Olcott

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

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

    On 4/1/2022 7:52 AM, Richard Damon wrote:
    On 4/1/22 8:08 AM, olcott wrote:
    On 4/1/2022 6:36 AM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote:
    On 3/31/2022 10:16 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote:
    On 3/31/2022 9:34 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott wrote: >>>>>>>> On 3/31/2022 9:23 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott wrote: >>>>>>>>>> On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO BE >>>>>>>>>>>>>> REJECTED:

    Linz and everyone here believes that deciders must base >>>>>>>>>>>>>> their decision
    on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ >>>>>>>>>>>>>> over-ruling the
    actual behavior specified by the actual finite string >>>>>>>>>>>>>> actual input.
    Here's that question you would not answer without
    equivocating, even
    after my asking it more than 12 times in a row. André also >>>>>>>>>>>>> asked many,
    many times and got no answer.
    What string must be passed to H so that H can tell us >>>>>>>>>>>>> whether or not Ĥ
    applied to ⟨Ĥ⟩ halts? Do you reject even the idea that a >>>>>>>>>>>>> halt decider
    could tell us whether a particular TM does or does not halt >>>>>>>>>>>>> when given
    some particular input? Isn't that what the theorem is >>>>>>>>>>>>> about? (The
    answer is, of course, yes.)

    DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE DIFFERENT >>>>>>>>>>>> BEHAVIOR.

    The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be >>>>>>>>>>>> computationally
    equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ yet >>>>>>>>>>>> not the
    same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.

    Failure to answer number one (or 13 if you count my previous >>>>>>>>>>> attempts).
    Here's the question in case you missed it:

    What string must be passed to H so that H can tell us whether >>>>>>>>>>> or not Ĥ
    applied to ⟨Ĥ⟩ halts?
    I worked out many of the details of this, and can see why you >>>>>>>>>> believe it
    is an important point, I will not begin to discuss this
    until after you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the >>>>>>>>>> basis that
    the correctly simulated input to embedded_H would never reach >>>>>>>>>> its own
    final state in any finite number of simulated steps.

    embedded_Ha, and therefore Ha, is not correct to reject
    <Ha^><Ha^> because it quits its simulation after n steps which >>>>>>>>> is too soon. When this same input is given to simulating halt >>>>>>>>> decider Hb which simulates for n+k steps, the input does reach >>>>>>>>> its final state after n+k steps and Hb accepts <Ha^><Ha^>.
    Therefore Ha, and subsequently embedded_Ha, does *not*
    correctly simulate its input.
    I will simply say that I am ignoring another strawman error.

    Just saying "strawman" isn't good enough.
    I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated semantics >>>>>> any
    change in notation or semantics is off topic.

    I am sure that you can make a million halt deciders that don't
    work they
    are all strawman.

    So you can't explain why Hb is wrong, and have therefore implicitly
    admitted it is correct.

    So what are you doing to do now that your proof has been refuted?
    That you can make up some screwy thing that doesn't work says nothing
    about my proof. If you were talking about my proof then you have to use >>>> my notation, my semantics and find an error in that.

    How exactly is it that Hb "doesn't work"?

    When you talk about H / embedded_H that "correctly" reports
    non-halting for H^, you're talking about an H that aborts it's
    simulation.  That's Ha / embedded_Ha and Ha^ is built from that.
    What I said still stands.  So state why Hb is wrong or admit failure.


    On 3/31/2022 9:23 PM, Dennis Bush wrote:
    embedded_Ha, and therefore Ha, is not correct to reject <Ha^><Ha^>
    because it quits its simulation after n steps which is too soon.  When
    this same input is given to simulating halt decider Hb which simulates
    for n+k steps, the input does reach its final state after n+k steps
    and Hb accepts <Ha^><Ha^>.  Therefore Ha, and subsequently
    embedded_Ha, does *not* correctly simulate its input.

    It is like I talk about driving my car to show that my car can be
    driven so you drive a car into a tree to show that a car cannot be
    driven.

    Here are the simplified notational conventions and semantics:
    (Any attempt to diverge from the specified semantics will be construed
    as the strawman error and marked as ignored)

    We will just call the halt decider H:
    H ⟨p⟩ ⟨i⟩ ⊢* H.qy   iff UTM simulated ⟨p⟩ ⟨i⟩ reaches its final state
    H ⟨p⟩ ⟨i⟩ ⊢* H.qn   iff UTM simulated ⟨p⟩ ⟨i⟩ would never reach its
    final state

    Simplified Ĥ directly calls H --- infinite loop has been removed.
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn


    THe problem with your 'simplified' H^ is that a smart H could just
    answer by going to Qy and be correct, but since yours doesn't, that
    isn't a fatal flaw to your argument.

    H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> -> H.Qn only
    if UTM simulaton of <p> <i> will never halt, but we show that since UTM simulation of <H^> <H^> is the same as H^ applied to <H^> and that goes
    to H.Qn and HALTS, so does the UTM Simulation.


    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩

    // while every H remains in pure UTM mode
    Then these steps would keep repeating:
    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...


    --
    Copyright 2022 Pete Olcott

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

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

    On 4/1/2022 9:03 AM, Richard Damon wrote:
    On 4/1/22 9:25 AM, olcott wrote:
    On 4/1/2022 7:52 AM, Richard Damon wrote:
    On 4/1/22 8:08 AM, olcott wrote:
    On 4/1/2022 6:36 AM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote:
    On 3/31/2022 10:16 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote: >>>>>>>> On 3/31/2022 9:34 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott wrote: >>>>>>>>>> On 3/31/2022 9:23 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO BE >>>>>>>>>>>>>>>> REJECTED:

    Linz and everyone here believes that deciders must base >>>>>>>>>>>>>>>> their decision
    on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ >>>>>>>>>>>>>>>> over-ruling the
    actual behavior specified by the actual finite string >>>>>>>>>>>>>>>> actual input.
    Here's that question you would not answer without >>>>>>>>>>>>>>> equivocating, even
    after my asking it more than 12 times in a row. André >>>>>>>>>>>>>>> also asked many,
    many times and got no answer.
    What string must be passed to H so that H can tell us >>>>>>>>>>>>>>> whether or not Ĥ
    applied to ⟨Ĥ⟩ halts? Do you reject even the idea that a >>>>>>>>>>>>>>> halt decider
    could tell us whether a particular TM does or does not >>>>>>>>>>>>>>> halt when given
    some particular input? Isn't that what the theorem is >>>>>>>>>>>>>>> about? (The
    answer is, of course, yes.)

    DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE DIFFERENT >>>>>>>>>>>>>> BEHAVIOR.

    The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be
    computationally
    equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ yet >>>>>>>>>>>>>> not the
    same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.

    Failure to answer number one (or 13 if you count my
    previous attempts).
    Here's the question in case you missed it:

    What string must be passed to H so that H can tell us >>>>>>>>>>>>> whether or not Ĥ
    applied to ⟨Ĥ⟩ halts?
    I worked out many of the details of this, and can see why >>>>>>>>>>>> you believe it
    is an important point, I will not begin to discuss this >>>>>>>>>>>> until after you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the
    basis that
    the correctly simulated input to embedded_H would never >>>>>>>>>>>> reach its own
    final state in any finite number of simulated steps.

    embedded_Ha, and therefore Ha, is not correct to reject
    <Ha^><Ha^> because it quits its simulation after n steps >>>>>>>>>>> which is too soon. When this same input is given to
    simulating halt decider Hb which simulates for n+k steps, the >>>>>>>>>>> input does reach its final state after n+k steps and Hb
    accepts <Ha^><Ha^>. Therefore Ha, and subsequently
    embedded_Ha, does *not* correctly simulate its input.
    I will simply say that I am ignoring another strawman error. >>>>>>>>>
    Just saying "strawman" isn't good enough.
    I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated >>>>>>>> semantics any
    change in notation or semantics is off topic.

    I am sure that you can make a million halt deciders that don't >>>>>>>> work they
    are all strawman.

    So you can't explain why Hb is wrong, and have therefore
    implicitly admitted it is correct.

    So what are you doing to do now that your proof has been refuted? >>>>>> That you can make up some screwy thing that doesn't work says nothing >>>>>> about my proof. If you were talking about my proof then you have
    to use
    my notation, my semantics and find an error in that.

    How exactly is it that Hb "doesn't work"?

    When you talk about H / embedded_H that "correctly" reports
    non-halting for H^, you're talking about an H that aborts it's
    simulation.  That's Ha / embedded_Ha and Ha^ is built from that.
    What I said still stands.  So state why Hb is wrong or admit failure. >>>>>

    On 3/31/2022 9:23 PM, Dennis Bush wrote:
    embedded_Ha, and therefore Ha, is not correct to reject
    <Ha^><Ha^> because it quits its simulation after n steps which is
    too soon. When this same input is given to simulating halt decider
    Hb which simulates for n+k steps, the input does reach its final
    state after n+k steps and Hb accepts <Ha^><Ha^>.  Therefore Ha, and
    subsequently embedded_Ha, does *not* correctly simulate its input.

    It is like I talk about driving my car to show that my car can be
    driven so you drive a car into a tree to show that a car cannot be
    driven.

    Here are the simplified notational conventions and semantics:
    (Any attempt to diverge from the specified semantics will be
    construed as the strawman error and marked as ignored)

    We will just call the halt decider H:
    H ⟨p⟩ ⟨i⟩ ⊢* H.qy   iff UTM simulated ⟨p⟩ ⟨i⟩ reaches its final state
    H ⟨p⟩ ⟨i⟩ ⊢* H.qn   iff UTM simulated ⟨p⟩ ⟨i⟩ would never reach its
    final state

    Simplified Ĥ directly calls H --- infinite loop has been removed.
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn


    THe problem with your 'simplified' H^ is that a smart H could just
    answer by going to Qy and be correct, but since yours doesn't, that
    isn't a fatal flaw to your argument.

    H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> -> H.Qn
    only if UTM simulaton of <p> <i> will never halt, but we show that
    since UTM simulation of <H^> <H^> is the same as H^ applied to <H^>
    and that goes to H.Qn and HALTS, so does the UTM Simulation.


    When Ĥ is applied to ⟨Ĥ⟩
       Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩

    // while every H remains in pure UTM mode
    Then these steps would keep repeating:
       Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
       Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
       Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...



    No such thing as 'UTM Mode', a machine either is or is not a UTM.

    A simulating halt decider is in UTM mode while the behavior of its input remains computationally equivalent to the behavior of this same input
    when simulated by a UTM.


    --
    Copyright 2022 Pete Olcott

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

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

    On 4/1/2022 9:28 AM, Richard Damon wrote:
    On 4/1/22 10:11 AM, olcott wrote:
    On 4/1/2022 9:03 AM, Richard Damon wrote:
    On 4/1/22 9:25 AM, olcott wrote:
    On 4/1/2022 7:52 AM, Richard Damon wrote:
    On 4/1/22 8:08 AM, olcott wrote:
    On 4/1/2022 6:36 AM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote: >>>>>>>> On 3/31/2022 10:16 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote: >>>>>>>>>> On 3/31/2022 9:34 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 3/31/2022 9:23 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO >>>>>>>>>>>>>>>>>> BE REJECTED:

    Linz and everyone here believes that deciders must >>>>>>>>>>>>>>>>>> base their decision
    on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ >>>>>>>>>>>>>>>>>> over-ruling the
    actual behavior specified by the actual finite string >>>>>>>>>>>>>>>>>> actual input.
    Here's that question you would not answer without >>>>>>>>>>>>>>>>> equivocating, even
    after my asking it more than 12 times in a row. André >>>>>>>>>>>>>>>>> also asked many,
    many times and got no answer.
    What string must be passed to H so that H can tell us >>>>>>>>>>>>>>>>> whether or not Ĥ
    applied to ⟨Ĥ⟩ halts? Do you reject even the idea that >>>>>>>>>>>>>>>>> a halt decider
    could tell us whether a particular TM does or does not >>>>>>>>>>>>>>>>> halt when given
    some particular input? Isn't that what the theorem is >>>>>>>>>>>>>>>>> about? (The
    answer is, of course, yes.)

    DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE >>>>>>>>>>>>>>>> DIFFERENT BEHAVIOR.

    The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be
    computationally
    equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ >>>>>>>>>>>>>>>> yet not the
    same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ. >>>>>>>>>>>>>>>
    Failure to answer number one (or 13 if you count my >>>>>>>>>>>>>>> previous attempts).
    Here's the question in case you missed it:

    What string must be passed to H so that H can tell us >>>>>>>>>>>>>>> whether or not Ĥ
    applied to ⟨Ĥ⟩ halts?
    I worked out many of the details of this, and can see why >>>>>>>>>>>>>> you believe it
    is an important point, I will not begin to discuss this >>>>>>>>>>>>>> until after you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the
    basis that
    the correctly simulated input to embedded_H would never >>>>>>>>>>>>>> reach its own
    final state in any finite number of simulated steps. >>>>>>>>>>>>>
    embedded_Ha, and therefore Ha, is not correct to reject >>>>>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n steps >>>>>>>>>>>>> which is too soon. When this same input is given to
    simulating halt decider Hb which simulates for n+k steps, >>>>>>>>>>>>> the input does reach its final state after n+k steps and Hb >>>>>>>>>>>>> accepts <Ha^><Ha^>. Therefore Ha, and subsequently
    embedded_Ha, does *not* correctly simulate its input. >>>>>>>>>>>> I will simply say that I am ignoring another strawman error. >>>>>>>>>>>
    Just saying "strawman" isn't good enough.
    I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated >>>>>>>>>> semantics any
    change in notation or semantics is off topic.

    I am sure that you can make a million halt deciders that don't >>>>>>>>>> work they
    are all strawman.

    So you can't explain why Hb is wrong, and have therefore
    implicitly admitted it is correct.

    So what are you doing to do now that your proof has been refuted? >>>>>>>> That you can make up some screwy thing that doesn't work says
    nothing
    about my proof. If you were talking about my proof then you have >>>>>>>> to use
    my notation, my semantics and find an error in that.

    How exactly is it that Hb "doesn't work"?

    When you talk about H / embedded_H that "correctly" reports
    non-halting for H^, you're talking about an H that aborts it's
    simulation.  That's Ha / embedded_Ha and Ha^ is built from that. >>>>>>> What I said still stands.  So state why Hb is wrong or admit
    failure.


    On 3/31/2022 9:23 PM, Dennis Bush wrote:
    embedded_Ha, and therefore Ha, is not correct to reject
    <Ha^><Ha^> because it quits its simulation after n steps which is
    too soon. When this same input is given to simulating halt decider >>>>>> Hb which simulates for n+k steps, the input does reach its final
    state after n+k steps and Hb accepts <Ha^><Ha^>.  Therefore Ha,
    and subsequently embedded_Ha, does *not* correctly simulate its
    input.

    It is like I talk about driving my car to show that my car can be
    driven so you drive a car into a tree to show that a car cannot be >>>>>> driven.

    Here are the simplified notational conventions and semantics:
    (Any attempt to diverge from the specified semantics will be
    construed as the strawman error and marked as ignored)

    We will just call the halt decider H:
    H ⟨p⟩ ⟨i⟩ ⊢* H.qy   iff UTM simulated ⟨p⟩ ⟨i⟩ reaches its final state
    H ⟨p⟩ ⟨i⟩ ⊢* H.qn   iff UTM simulated ⟨p⟩ ⟨i⟩ would never reach
    its final state

    Simplified Ĥ directly calls H --- infinite loop has been removed. >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn


    THe problem with your 'simplified' H^ is that a smart H could just
    answer by going to Qy and be correct, but since yours doesn't, that
    isn't a fatal flaw to your argument.

    H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> -> H.Qn
    only if UTM simulaton of <p> <i> will never halt, but we show that
    since UTM simulation of <H^> <H^> is the same as H^ applied to <H^>
    and that goes to H.Qn and HALTS, so does the UTM Simulation.


    When Ĥ is applied to ⟨Ĥ⟩
       Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩

    // while every H remains in pure UTM mode
    Then these steps would keep repeating:
       Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
       Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
       Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...



    No such thing as 'UTM Mode', a machine either is or is not a UTM.

    A simulating halt decider is in UTM mode while the behavior of its
    input remains computationally equivalent to the behavior of this same
    input when simulated by a UTM.



    Nope, just shows you don't understand what a UTM is.

    Any Turing machine can have the full capability of a UTM within it that
    it can use to simulate the Turing Machine description of any halting computation to completion. It can also simulate one single state
    transition at a time as a sequence of simulated steps.

    Although it is not a UTM the behavior of the simulated input while the simulating halt decider is in UTM mode is equivalent to its behavior
    when simulated by an actual UTM.

    --
    Copyright 2022 Pete Olcott

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

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

    On 4/1/2022 10:35 AM, Richard Damon wrote:
    On 4/1/22 11:20 AM, olcott wrote:
    On 4/1/2022 9:28 AM, Richard Damon wrote:
    On 4/1/22 10:11 AM, olcott wrote:
    On 4/1/2022 9:03 AM, Richard Damon wrote:
    On 4/1/22 9:25 AM, olcott wrote:
    On 4/1/2022 7:52 AM, Richard Damon wrote:
    On 4/1/22 8:08 AM, olcott wrote:
    On 4/1/2022 6:36 AM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote: >>>>>>>>>> On 3/31/2022 10:16 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 3/31/2022 9:34 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott >>>>>>>>>>>>> wrote:
    On 3/31/2022 9:23 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott >>>>>>>>>>>>>>> wrote:
    On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 3/31/2022 11:09 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:

    IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO >>>>>>>>>>>>>>>>>>>> BE REJECTED:

    Linz and everyone here believes that deciders must >>>>>>>>>>>>>>>>>>>> base their decision
    on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ >>>>>>>>>>>>>>>>>>>> over-ruling the
    actual behavior specified by the actual finite >>>>>>>>>>>>>>>>>>>> string actual input.
    Here's that question you would not answer without >>>>>>>>>>>>>>>>>>> equivocating, even
    after my asking it more than 12 times in a row. André >>>>>>>>>>>>>>>>>>> also asked many,
    many times and got no answer.
    What string must be passed to H so that H can tell us >>>>>>>>>>>>>>>>>>> whether or not Ĥ
    applied to ⟨Ĥ⟩ halts? Do you reject even the idea >>>>>>>>>>>>>>>>>>> that a halt decider
    could tell us whether a particular TM does or does >>>>>>>>>>>>>>>>>>> not halt when given
    some particular input? Isn't that what the theorem is >>>>>>>>>>>>>>>>>>> about? (The
    answer is, of course, yes.)

    DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE >>>>>>>>>>>>>>>>>> DIFFERENT BEHAVIOR.

    The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be
    computationally
    equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ >>>>>>>>>>>>>>>>>> yet not the
    same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ. >>>>>>>>>>>>>>>>>
    Failure to answer number one (or 13 if you count my >>>>>>>>>>>>>>>>> previous attempts).
    Here's the question in case you missed it:

    What string must be passed to H so that H can tell us >>>>>>>>>>>>>>>>> whether or not Ĥ
    applied to ⟨Ĥ⟩ halts?
    I worked out many of the details of this, and can see >>>>>>>>>>>>>>>> why you believe it
    is an important point, I will not begin to discuss this >>>>>>>>>>>>>>>> until after you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on
    the basis that
    the correctly simulated input to embedded_H would never >>>>>>>>>>>>>>>> reach its own
    final state in any finite number of simulated steps. >>>>>>>>>>>>>>>
    embedded_Ha, and therefore Ha, is not correct to reject >>>>>>>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n steps >>>>>>>>>>>>>>> which is too soon. When this same input is given to >>>>>>>>>>>>>>> simulating halt decider Hb which simulates for n+k steps, >>>>>>>>>>>>>>> the input does reach its final state after n+k steps and >>>>>>>>>>>>>>> Hb accepts <Ha^><Ha^>. Therefore Ha, and subsequently >>>>>>>>>>>>>>> embedded_Ha, does *not* correctly simulate its input. >>>>>>>>>>>>>> I will simply say that I am ignoring another strawman error. >>>>>>>>>>>>>
    Just saying "strawman" isn't good enough.
    I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated >>>>>>>>>>>> semantics any
    change in notation or semantics is off topic.

    I am sure that you can make a million halt deciders that >>>>>>>>>>>> don't work they
    are all strawman.

    So you can't explain why Hb is wrong, and have therefore >>>>>>>>>>> implicitly admitted it is correct.

    So what are you doing to do now that your proof has been >>>>>>>>>>> refuted?
    That you can make up some screwy thing that doesn't work says >>>>>>>>>> nothing
    about my proof. If you were talking about my proof then you >>>>>>>>>> have to use
    my notation, my semantics and find an error in that.

    How exactly is it that Hb "doesn't work"?

    When you talk about H / embedded_H that "correctly" reports
    non-halting for H^, you're talking about an H that aborts it's >>>>>>>>> simulation.  That's Ha / embedded_Ha and Ha^ is built from
    that. What I said still stands.  So state why Hb is wrong or >>>>>>>>> admit failure.


    On 3/31/2022 9:23 PM, Dennis Bush wrote:
    embedded_Ha, and therefore Ha, is not correct to reject
    <Ha^><Ha^> because it quits its simulation after n steps which >>>>>>>> is too soon. When this same input is given to simulating halt
    decider Hb which simulates for n+k steps, the input does reach >>>>>>>> its final state after n+k steps and Hb accepts <Ha^><Ha^>.
    Therefore Ha, and subsequently embedded_Ha, does *not* correctly >>>>>>>> simulate its input.

    It is like I talk about driving my car to show that my car can >>>>>>>> be driven so you drive a car into a tree to show that a car
    cannot be driven.

    Here are the simplified notational conventions and semantics:
    (Any attempt to diverge from the specified semantics will be
    construed as the strawman error and marked as ignored)

    We will just call the halt decider H:
    H ⟨p⟩ ⟨i⟩ ⊢* H.qy   iff UTM simulated ⟨p⟩ ⟨i⟩ reaches its final
    state
    H ⟨p⟩ ⟨i⟩ ⊢* H.qn   iff UTM simulated ⟨p⟩ ⟨i⟩ would never reach
    its final state

    Simplified Ĥ directly calls H --- infinite loop has been removed. >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn


    THe problem with your 'simplified' H^ is that a smart H could
    just answer by going to Qy and be correct, but since yours
    doesn't, that isn't a fatal flaw to your argument.

    H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> ->
    H.Qn only if UTM simulaton of <p> <i> will never halt, but we
    show that since UTM simulation of <H^> <H^> is the same as H^
    applied to <H^> and that goes to H.Qn and HALTS, so does the UTM >>>>>>> Simulation.


    When Ĥ is applied to ⟨Ĥ⟩
       Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩

    // while every H remains in pure UTM mode
    Then these steps would keep repeating:
       Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
       Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
       Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...



    No such thing as 'UTM Mode', a machine either is or is not a UTM.

    A simulating halt decider is in UTM mode while the behavior of its
    input remains computationally equivalent to the behavior of this
    same input when simulated by a UTM.



    Nope, just shows you don't understand what a UTM is.

    Any Turing machine can have the full capability of a UTM within it
    that it can use to simulate the Turing Machine description of any
    halting computation to completion. It can also simulate one single
    state transition at a time as a sequence of simulated steps.

    Although it is not a UTM the behavior of the simulated input while the
    simulating halt decider is in UTM mode is equivalent to its behavior
    when simulated by an actual UTM.


    Yes, it can use UTM code modified to perform some action.

    The final machine is NOT a UTM unless it meets the actual definiton of a
    UTM.

    Just like you can take a 'street-legal' car, and modify it for some
    purpose, and it may no longer be 'street-legal'

    If H no longer meets the definition of a UTM, then it isn't a UTM, even
    if it used UTM like code to make its decision.

    Since H LEAVES UTM mode,

    It does not always level UTM mode.
    Some inputs specify halting computations.

    the behavior of the machine it is simulating,
    if it contains a copy of H, must be simulated and analyised under the condition of considering that it too will leave UTM mode.


    When H rejects its input this means that the simulated input would never
    reach its own final state under any condition: aborted or infinitely
    simulated.

    Thus H considering its inputs behavior ONLY under the condition that the input will stay in UTM is UNSOUND LOGIC, based on a FALSE PREMISE.

    This is why your whole arguement fails.

    YOU ARE JUST WRONG.

    FAIL.

    You keep believing that an aborted simulation means that the simulated
    input halted even though you already defined that an aborted input is an
    input that has had its execution suspended and did not halt.

    --
    Copyright 2022 Pete Olcott

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

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

    On 4/1/2022 10:56 AM, Richard Damon wrote:
    On 4/1/22 11:45 AM, olcott wrote:
    On 4/1/2022 10:35 AM, Richard Damon wrote:
    On 4/1/22 11:20 AM, olcott wrote:
    On 4/1/2022 9:28 AM, Richard Damon wrote:
    On 4/1/22 10:11 AM, olcott wrote:
    On 4/1/2022 9:03 AM, Richard Damon wrote:
    On 4/1/22 9:25 AM, olcott wrote:
    On 4/1/2022 7:52 AM, Richard Damon wrote:
    On 4/1/22 8:08 AM, olcott wrote:
    On 4/1/2022 6:36 AM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 3/31/2022 10:16 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott >>>>>>>>>>>>> wrote:
    On 3/31/2022 9:34 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott >>>>>>>>>>>>>>> wrote:
    On 3/31/2022 9:23 PM, Dennis Bush wrote:
    On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott >>>>>>>>>>>>>>>>> wrote:
    On 3/31/2022 3:27 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:

    On 3/31/2022 11:09 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:

    IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF >>>>>>>>>>>>>>>>>>>>>> TO BE REJECTED:

    Linz and everyone here believes that deciders must >>>>>>>>>>>>>>>>>>>>>> base their decision
    on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ >>>>>>>>>>>>>>>>>>>>>> over-ruling the
    actual behavior specified by the actual finite >>>>>>>>>>>>>>>>>>>>>> string actual input.
    Here's that question you would not answer without >>>>>>>>>>>>>>>>>>>>> equivocating, even
    after my asking it more than 12 times in a row. >>>>>>>>>>>>>>>>>>>>> André also asked many,
    many times and got no answer.
    What string must be passed to H so that H can tell >>>>>>>>>>>>>>>>>>>>> us whether or not Ĥ
    applied to ⟨Ĥ⟩ halts? Do you reject even the idea >>>>>>>>>>>>>>>>>>>>> that a halt decider
    could tell us whether a particular TM does or does >>>>>>>>>>>>>>>>>>>>> not halt when given
    some particular input? Isn't that what the theorem >>>>>>>>>>>>>>>>>>>>> is about? (The
    answer is, of course, yes.)

    DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE >>>>>>>>>>>>>>>>>>>> DIFFERENT BEHAVIOR.

    The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must
    be computationally
    equivalent to the direct execution of Ĥ applied to >>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ yet not the
    same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ. >>>>>>>>>>>>>>>>>>>
    Failure to answer number one (or 13 if you count my >>>>>>>>>>>>>>>>>>> previous attempts).
    Here's the question in case you missed it: >>>>>>>>>>>>>>>>>>>
    What string must be passed to H so that H can tell us >>>>>>>>>>>>>>>>>>> whether or not Ĥ
    applied to ⟨Ĥ⟩ halts?
    I worked out many of the details of this, and can see >>>>>>>>>>>>>>>>>> why you believe it
    is an important point, I will not begin to discuss this >>>>>>>>>>>>>>>>>> until after you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on
    the basis that
    the correctly simulated input to embedded_H would >>>>>>>>>>>>>>>>>> never reach its own
    final state in any finite number of simulated steps. >>>>>>>>>>>>>>>>>
    embedded_Ha, and therefore Ha, is not correct to reject >>>>>>>>>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n >>>>>>>>>>>>>>>>> steps which is too soon. When this same input is given >>>>>>>>>>>>>>>>> to simulating halt decider Hb which simulates for n+k >>>>>>>>>>>>>>>>> steps, the input does reach its final state after n+k >>>>>>>>>>>>>>>>> steps and Hb accepts <Ha^><Ha^>. Therefore Ha, and >>>>>>>>>>>>>>>>> subsequently embedded_Ha, does *not* correctly simulate >>>>>>>>>>>>>>>>> its input.
    I will simply say that I am ignoring another strawman >>>>>>>>>>>>>>>> error.

    Just saying "strawman" isn't good enough.
    I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated >>>>>>>>>>>>>> semantics any
    change in notation or semantics is off topic.

    I am sure that you can make a million halt deciders that >>>>>>>>>>>>>> don't work they
    are all strawman.

    So you can't explain why Hb is wrong, and have therefore >>>>>>>>>>>>> implicitly admitted it is correct.

    So what are you doing to do now that your proof has been >>>>>>>>>>>>> refuted?
    That you can make up some screwy thing that doesn't work >>>>>>>>>>>> says nothing
    about my proof. If you were talking about my proof then you >>>>>>>>>>>> have to use
    my notation, my semantics and find an error in that.

    How exactly is it that Hb "doesn't work"?

    When you talk about H / embedded_H that "correctly" reports >>>>>>>>>>> non-halting for H^, you're talking about an H that aborts >>>>>>>>>>> it's simulation.  That's Ha / embedded_Ha and Ha^ is built >>>>>>>>>>> from that. What I said still stands.  So state why Hb is >>>>>>>>>>> wrong or admit failure.


    On 3/31/2022 9:23 PM, Dennis Bush wrote:
    embedded_Ha, and therefore Ha, is not correct to reject >>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n steps which >>>>>>>>>> is too soon. When this same input is given to simulating halt >>>>>>>>>> decider Hb which simulates for n+k steps, the input does reach >>>>>>>>>> its final state after n+k steps and Hb accepts <Ha^><Ha^>. >>>>>>>>>> Therefore Ha, and subsequently embedded_Ha, does *not*
    correctly simulate its input.

    It is like I talk about driving my car to show that my car can >>>>>>>>>> be driven so you drive a car into a tree to show that a car >>>>>>>>>> cannot be driven.

    Here are the simplified notational conventions and semantics: >>>>>>>>>> (Any attempt to diverge from the specified semantics will be >>>>>>>>>> construed as the strawman error and marked as ignored)

    We will just call the halt decider H:
    H ⟨p⟩ ⟨i⟩ ⊢* H.qy   iff UTM simulated ⟨p⟩ ⟨i⟩ reaches its
    final state
    H ⟨p⟩ ⟨i⟩ ⊢* H.qn   iff UTM simulated ⟨p⟩ ⟨i⟩ would never
    reach its final state

    Simplified Ĥ directly calls H --- infinite loop has been removed. >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn


    THe problem with your 'simplified' H^ is that a smart H could >>>>>>>>> just answer by going to Qy and be correct, but since yours
    doesn't, that isn't a fatal flaw to your argument.

    H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> -> >>>>>>>>> H.Qn only if UTM simulaton of <p> <i> will never halt, but we >>>>>>>>> show that since UTM simulation of <H^> <H^> is the same as H^ >>>>>>>>> applied to <H^> and that goes to H.Qn and HALTS, so does the >>>>>>>>> UTM Simulation.


    When Ĥ is applied to ⟨Ĥ⟩
       Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩

    // while every H remains in pure UTM mode
    Then these steps would keep repeating:
       Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
       Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
       Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...



    No such thing as 'UTM Mode', a machine either is or is not a UTM. >>>>>>
    A simulating halt decider is in UTM mode while the behavior of its >>>>>> input remains computationally equivalent to the behavior of this
    same input when simulated by a UTM.



    Nope, just shows you don't understand what a UTM is.

    Any Turing machine can have the full capability of a UTM within it
    that it can use to simulate the Turing Machine description of any
    halting computation to completion. It can also simulate one single
    state transition at a time as a sequence of simulated steps.

    Although it is not a UTM the behavior of the simulated input while
    the simulating halt decider is in UTM mode is equivalent to its
    behavior when simulated by an actual UTM.


    Yes, it can use UTM code modified to perform some action.

    The final machine is NOT a UTM unless it meets the actual definiton
    of a UTM.

    Just like you can take a 'street-legal' car, and modify it for some
    purpose, and it may no longer be 'street-legal'

    If H no longer meets the definition of a UTM, then it isn't a UTM,
    even if it used UTM like code to make its decision.

    Since H LEAVES UTM mode,

    It does not always level UTM mode.
    Some inputs specify halting computations.

    But not this case.

    Yes, there are cases where it won't leave UTM mode, and for those it
    doesn't need to consider that case, but if it will leave UTM mode, it
    needs to consider that.

    In particular, any input it wants to call non-halting, it MUST consider
    that it WILL leave UTM mode.

    For H <H^> <H^> we have established that H MUST leave UTM mode or it
    fails to be a decider.

    You are just going to your Red Herring Strawman.


    the behavior of the machine it is simulating, if it contains a copy
    of H, must be simulated and analyised under the condition of
    considering that it too will leave UTM mode.


    When H rejects its input this means that the simulated input would
    never reach its own final state under any condition: aborted or
    infinitely simulated.

    Nope. If H -> Qn, then the CORRECT simulation (by a REAL UTM) of <H^>
    <H^> Halts, BECAUSE H^ applied to <H^> halts, because it sees its copy
    of H -> Qn.

    It is your inaccurate notational conventions that cause you to keep
    getting this incorrectly.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

    There is never a case where the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ ever reaches its own
    final state of ⟨Ĥ.H.qy⟩ or ⟨Ĥ.H.qn⟩


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