• Re: Simulating halt deciders correct decider halting [ Ben's perpetual

    From olcott@21:1/5 to Ben Bacarisse on Wed Mar 2 17:35:31 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/2/2022 11:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Linz confuses himself my making the TM descriptions less than a clear >>>>>> as possible.

    Have you looked at Linz's actual proof yet? It's theorem 12.2, a page >>>>> further on from the one you seem to be obsessed by.

    Like I said my only reply to you will be to keep repeating the key
    points that you failed to address until you address them completely.
    I can't parse that sentence but it contains no hint that you have looked >>> at Linz's proof yet.

    Do you understand that a decider computes the mapping ONLY from its
    inputs to an accept or reject state and does not compute any other
    mapping?

    So no, you have not looked at Linz's proof yet.

    By the way, I am not going to answer patronising questions. But by all
    means ask me to tell you what a decider is, provided you are prepared to
    use that definition (and terminology) in future exchanges.


    You have proven that you do not understand that deciders ONLY compute
    the mapping from their inputs to an accept or reject state by
    perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ has anything
    to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.

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

    The embedded copy of H at Ĥ.qx does not compute the halt status of
    itself or the computation that contains it: Ĥ ⟨Ĥ⟩.




    --
    Copyright 2021 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 Wed Mar 2 18:29:19 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/2/2022 6:16 PM, Richard Damon wrote:
    On 3/2/22 6:35 PM, olcott wrote:
    On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/2/2022 11:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Linz confuses himself my making the TM descriptions less than a >>>>>>>> clear
    as possible.

    Have you looked at Linz's actual proof yet?  It's theorem 12.2, a >>>>>>> page
    further on from the one you seem to be obsessed by.

    Like I said my only reply to you will be to keep repeating the key >>>>>> points that you failed to address until you address them completely. >>>>> I can't parse that sentence but it contains no hint that you have
    looked
    at Linz's proof yet.

    Do you understand that a decider computes the mapping ONLY from its
    inputs to an accept or reject state and does not compute any other
    mapping?

    So no, you have not looked at Linz's proof yet.

    By the way, I am not going to answer patronising questions.  But by all >>> means ask me to tell you what a decider is, provided you are prepared to >>> use that definition (and terminology) in future exchanges.


    You have proven that you do not understand that deciders ONLY compute
    the mapping from their inputs to an accept or reject state by
    perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ has anything >> to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.

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

    The embedded copy of H at Ĥ.qx does not compute the halt status of
    itself or the computation that contains it: Ĥ ⟨Ĥ⟩.


    Then it isn't a Halt Decider. Thanks for making that Clear.

    FAIL,


    You too are not aware that deciders ONLY compute the mapping from their
    inputs to an accept or reject state. You and Ben still think that
    deciders must compute mappings from non-inputs.

    --
    Copyright 2021 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 Wed Mar 2 20:13:57 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/2/2022 8:07 PM, Richard Damon wrote:
    On 3/2/22 8:09 PM, olcott wrote:
    On 3/2/2022 6:56 PM, Richard Damon wrote:
    On 3/2/22 7:29 PM, olcott wrote:
    On 3/2/2022 6:16 PM, Richard Damon wrote:
    On 3/2/22 6:35 PM, olcott wrote:
    On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/2/2022 11:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Linz confuses himself my making the TM descriptions less >>>>>>>>>>>> than a clear
    as possible.

    Have you looked at Linz's actual proof yet?  It's theorem >>>>>>>>>>> 12.2, a page
    further on from the one you seem to be obsessed by.

    Like I said my only reply to you will be to keep repeating the >>>>>>>>>> key
    points that you failed to address until you address them
    completely.
    I can't parse that sentence but it contains no hint that you >>>>>>>>> have looked
    at Linz's proof yet.

    Do you understand that a decider computes the mapping ONLY from its >>>>>>>> inputs to an accept or reject state and does not compute any other >>>>>>>> mapping?

    So no, you have not looked at Linz's proof yet.

    By the way, I am not going to answer patronising questions.  But >>>>>>> by all
    means ask me to tell you what a decider is, provided you are
    prepared to
    use that definition (and terminology) in future exchanges.


    You have proven that you do not understand that deciders ONLY
    compute the mapping from their inputs to an accept or reject state >>>>>> by perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ has >>>>>> anything to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.

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

    The embedded copy of H at Ĥ.qx does not compute the halt status of >>>>>> itself or the computation that contains it: Ĥ ⟨Ĥ⟩.


    Then it isn't a Halt Decider. Thanks for making that Clear.

    FAIL,


    You too are not aware that deciders ONLY compute the mapping from
    their inputs to an accept or reject state. You and Ben still think
    that deciders must compute mappings from non-inputs.


    Right, they compute the CORRECT mapping of their inputs, and the
    CORRECT mapping for a Halt Decider is H applied <M> w depends on the
    behavior of M applied to w, so H applied to <H^> <H^> IS responsible
    for the behavior of H^ applied to <H^> BY DEFINITION.

    So, your claim that this isn't what your H does, just PROVES that
    your H is NOT computing the Halting Function, and thus is NOT a Halt
    Decider.

    Thank you for admitting that, or are you just a pathological liar?

    The embedded copy of H at Ĥ.qx does not compute the halt status of
    itself or the computation that contains it: Ĥ ⟨Ĥ⟩.

    Ĥ ⟨Ĥ⟩ is not an input to embedded_H NITWIT
    Ĥ ⟨Ĥ⟩ is not an input to embedded_H NITWIT
    Ĥ ⟨Ĥ⟩ is not an input to embedded_H NITWIT
    Ĥ ⟨Ĥ⟩ is not an input to embedded_H NITWIT


    But it IS the thing that determine the correct answer for embedded_H if
    it is a Halt Decider, so it must not be.
    Because it is not an input to the decider it is out-of-scope for the
    decider. If I ask you: How long is your car? and you measure the height
    of your front door you gave me a wrong answer.


    --
    Copyright 2021 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 Wed Mar 2 21:21:08 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/2/2022 8:43 PM, Richard Damon wrote:
    On 3/2/22 9:36 PM, olcott wrote:
    On 3/2/2022 8:33 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/2/2022 11:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Linz confuses himself my making the TM descriptions less than >>>>>>>>>> a clear
    as possible.

    Have you looked at Linz's actual proof yet?  It's theorem 12.2, >>>>>>>>> a page
    further on from the one you seem to be obsessed by.

    Like I said my only reply to you will be to keep repeating the key >>>>>>>> points that you failed to address until you address them
    completely.
    I can't parse that sentence but it contains no hint that you have >>>>>>> looked
    at Linz's proof yet.

    Do you understand that a decider computes the mapping ONLY from its >>>>>> inputs to an accept or reject state and does not compute any other >>>>>> mapping?

    So no, you have not looked at Linz's proof yet.
    By the way, I am not going to answer patronising questions.  But by >>>>> all
    means ask me to tell you what a decider is, provided you are
    prepared to
    use that definition (and terminology) in future exchanges.

    You have proven that you do not understand that deciders ONLY compute
    the mapping from their inputs to an accept or reject state by
    perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ has anything
    to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.

    If you are prepared to learn with an open mind, I can take you through
    some exercises that will explain to you why this objection is
    groundless.  Of course, you can continue to spout nonsense -- that's no >>> problem for me -- but you claim to want to talk about this problem, and
    that involves understanding which strings to accept and which reject.


    You simply ignored my proof of my point proving that you are dishonest.


    Nope, you ignore the proofs that you are wrong, AND a Liar.

    Most often your rebuttals are only confused gibberish.

    Your key mistake is not having the slightest idea of how simulating halt deciders work even though I have explained it many hundreds of times.

    You keep thinking that if a simulating halt decider must abort its
    simulation to report that its input specifies a non-halting sequence of configurations that this makes this input halt and thus the reported non-halting wrong.

    _Infinite_Loop()
    [00000946](01) 55 push ebp
    [00000947](02) 8bec mov ebp,esp
    [00000949](02) ebfe jmp 00000949
    [0000094b](01) 5d pop ebp
    [0000094c](01) c3 ret
    Size in bytes:(0007) [0000094c]

    The above specifies an infinite loop even when its simulation has been
    aborted to report "infinite loop".

    --
    Copyright 2021 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 Thu Mar 3 09:52:40 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/2/2022 9:30 PM, Richard Damon wrote:
    On 3/2/22 10:21 PM, olcott wrote:
    On 3/2/2022 8:43 PM, Richard Damon wrote:
    On 3/2/22 9:36 PM, olcott wrote:
    On 3/2/2022 8:33 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/2/2022 11:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Linz confuses himself my making the TM descriptions less >>>>>>>>>>>> than a clear
    as possible.

    Have you looked at Linz's actual proof yet?  It's theorem >>>>>>>>>>> 12.2, a page
    further on from the one you seem to be obsessed by.

    Like I said my only reply to you will be to keep repeating the >>>>>>>>>> key
    points that you failed to address until you address them
    completely.
    I can't parse that sentence but it contains no hint that you >>>>>>>>> have looked
    at Linz's proof yet.

    Do you understand that a decider computes the mapping ONLY from its >>>>>>>> inputs to an accept or reject state and does not compute any other >>>>>>>> mapping?

    So no, you have not looked at Linz's proof yet.
    By the way, I am not going to answer patronising questions.  But >>>>>>> by all
    means ask me to tell you what a decider is, provided you are
    prepared to
    use that definition (and terminology) in future exchanges.

    You have proven that you do not understand that deciders ONLY compute >>>>>> the mapping from their inputs to an accept or reject state by
    perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ has >>>>>> anything
    to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. >>>>>
    If you are prepared to learn with an open mind, I can take you through >>>>> some exercises that will explain to you why this objection is
    groundless.  Of course, you can continue to spout nonsense --
    that's no
    problem for me -- but you claim to want to talk about this problem,
    and
    that involves understanding which strings to accept and which reject. >>>>>

    You simply ignored my proof of my point proving that you are dishonest. >>>>

    Nope, you ignore the proofs that you are wrong, AND a Liar.

    Most often your rebuttals are only confused gibberish.

    Your key mistake is not having the slightest idea of how simulating
    halt deciders work even though I have explained it many hundreds of
    times.

    You keep thinking that if a simulating halt decider must abort its
    simulation to report that its input specifies a non-halting sequence
    of configurations that this makes this input halt and thus the
    reported non-halting wrong.

    _Infinite_Loop()
    [00000946](01)  55              push ebp
    [00000947](02)  8bec            mov ebp,esp
    [00000949](02)  ebfe            jmp 00000949
    [0000094b](01)  5d              pop ebp
    [0000094c](01)  c3              ret
    Size in bytes:(0007) [0000094c]

    The above specifies an infinite loop even when its simulation has been
    aborted to report "infinite loop".


    It isn't the decider aborting that makes H^ Halting, it is H going to
    H.Qn that makes H^ non-halting (since H^ x will always go to H^.Qn and
    halt if H x x goes to H.Qn)


    As I have said many dozens of times now

    NON-HALTING CRITERION MEASURE
    It is universally true that when-so-ever a simulating halt decider must
    abort the simulation of its input to prevent the infinite simulation of
    this input that this input specifies an infinite sequence of
    configurations.

    When-so-ever the simulated input to a simulating halt decider
    demonstrates behavior that meets the NON-HALTING CRITERION MEASURE then
    the simulating halt decider is always correct to reject this input.

    The above is proved totally true entirely on the basis of the meaning of
    its words just like this: If we have a black cat then we know we have a
    cat.

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

    The copy of Linz H at Ĥ.qx is ONLY responsible for computing the mapping
    of its inputs to an accept or reject state.

    embedded_H is not responsible for determining the halt status of itself
    or the computation that contains it: Ĥ ⟨Ĥ⟩ because neither of these are inputs to embedded_H.


    H is perfectly allowed to abort its simulation and do something else,
    either loop forever or go to H.Qy, and H^ will stay non-halting, its
    just H didn't give the right answer.

    You are just confused about how cause and effect work.

    FAIL.




    --
    Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
    Genius hits a target no one else can see." Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Thu Mar 3 20:05:19 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/3/2022 7:14 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/3/2022 5:56 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    This is not about rehashing old points this is about evaluating new
    points.
    The eternal refrain of the Usenet crank: talk to me about this new
    nonsense; forget I ever said that old nonsense.
    My posts will be about whatever I want them to be about. Of course you
    will ignore all your old mistakes -- you ignored them when they were new >>> mistakes!

    I have proven that your rebuttals from six months ago are incorrect on
    the basis of a better analysis. It is OK if you want to chicken out,
    you are not my target audience.

    By my reckoning, you first claimed to have refuted every proof[1] of
    this simple theorem over 17 years ago. 17 years. How long can on paper
    take to finish?


    I have to make my proof so clearly correct that it is fully understood
    before it is rejected out-of-hand on the basis of its subject matter.

    I still need to learn more about computable functions. None of the
    theory of computation textbooks go into the same depth that others here
    refer to. I was not sure that a RASP computable function could know its
    own machine address until André's explanation.

    THIS IS THE KEY ESSENCE OF MY PROOF
    Infinitely Recursive input on HP Proofs
    comp.theory Mar 11, 2017, 3:13:03 PM peteolcott https://groups.google.com/g/comp.theory/c/NcFS02hKs1U/m/PlBF-1LRBAAJ

    I actually inadvertently came up with it in this paper:
    Self Modifying Turing Machine (SMTM) Solution to the Halting Problem
    (concrete example) August 2016

    https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example


    No one has actually pointing out any error in the essence of what I have
    said:

    Simple English version of Olcott's Halt status criterion measure:
    Every simulating halt decider that must abort the simulation of its
    input to prevent its infinite simulation correctly transitions to its
    reject state.

    Somewhat formalized version of Olcott's Halt status criterion measure:
    Let ⟨M⟩ describe a Turing machine M = (Q, Σ, Γ, δ, q₀, □, F), and let w
    be any element of Σ⁺, A solution of the halting problem is a Turing
    machine H, which for any ⟨M⟩ and w, performs the computation (Linz 1990:317)

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
    state of M

    Simulating halt decider H performs a pure simulation of its input as if
    it was a UTM unless and until it detects an infinitely repeating
    pattern. Then it aborts the simulation of its input and transitions to
    its final reject state. Otherwise H transitions to its accept state when
    its simulation ends.

    The above is mapped to the conventional notion of non-halting sequences
    of configurations in that they never reach their own final state.

    You are never going to get a paper on this topic published (published --
    not self-published). Whether you like it or not I am your target
    audience, along with anyone else here who will tell you that you are wrong[2]. That's why you are still replying to me despite having just
    said that you won't until I "fully address" whatever the latest junk
    idea was.

    Every single attempt you have made to undermine this simple theorem has
    been wrong. After almost 18 years of misunderstandings, daft ideas,
    deluded claims, doubling down and doubling back, there has not been a
    single idea that would get past a journal editor's joke pile. This
    includes the latest ridiculous misconception which I genuinely thought
    you might be able to overcome with a little coaching. But, no, you
    don't want to learn anything (though the offer remains open).

    With my human hat on, I really wish you would do something else. There
    is so much more to enjoy in the world. I know we share a love of dogs.
    I am learning to become a dog training instructor, and every week I get
    to work with dozens of owners and their amazing dogs. I love it. It's
    quite a change of style from academic computer science. Please consider
    some other use of your time.

    [1] Have you even read Linz's actual halting theorem proof yet? The
    proper one?

    [2] It's a curios fact that the one things that really annoys a Usenet
    crank is being agreed with. You'd think that all the Cantor deniers and Gödel refuters would get together a push a magnum opus (something they clearly can't do that on their own), but no. To paraphrase Tolstoy, all valid propositions are alike, but all crank ideas are wrong in their own particular way.



    --
    Copyright 2021 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 Thu Mar 3 21:39:39 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/3/2022 9:22 PM, Richard Damon wrote:

    On 3/3/22 10:05 PM, olcott wrote:
    On 3/3/2022 8:39 PM, Richard Damon wrote:
    On 3/3/22 9:05 PM, olcott wrote:
    On 3/3/2022 7:14 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/3/2022 5:56 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    This is not about rehashing old points this is about evaluating new >>>>>>>> points.
    The eternal refrain of the Usenet crank: talk to me about this new >>>>>>> nonsense; forget I ever said that old nonsense.
    My posts will be about whatever I want them to be about.  Of
    course you
    will ignore all your old mistakes -- you ignored them when they
    were new
    mistakes!

    I have proven that your rebuttals from six months ago are
    incorrect on
    the basis of a better analysis. It is OK if you want to chicken out, >>>>>> you are not my target audience.

    By my reckoning, you first claimed to have refuted every proof[1] of >>>>> this simple theorem over 17 years ago.  17 years.  How long can on >>>>> paper
    take to finish?


    I have to make my proof so clearly correct that it is fully
    understood before it is rejected out-of-hand on the basis of its
    subject matter.

    I still need to learn more about computable functions. None of the
    theory of computation textbooks go into the same depth that others
    here refer to. I was not sure that a RASP computable function could
    know its own machine address until André's explanation.

    So you ADMIT you don't know the basic meaning of things in the
    Theory, but you have made claims based on things that you claim are
    obvious by 'The meaning of the words' that include these terms.


    I did not know that a RASP function can know its own address and still
    be construed as a computation in computer science.


    The problem you are going to run into is that RASP machines don't have 'input' as generally constructed. This makes it harder to design a RASP machine that takes as an input the description of another arbitrary computation. (This is the same problem you 'H' program has).


    I have proven that I have refuted the halting problem proofs
    categorically. I only need to perfect my use of terminology.


    Not 'Perfect', first you need to learn the basics of the terminology.


    I know that all deciders compute the mapping from their input finite
    strings to an accept or reject state. You and Ben prove that you do not understand that halt deciders are deciders.



    THIS IS THE KEY ESSENCE OF MY PROOF
    Infinitely Recursive input on HP Proofs
    comp.theory  Mar 11, 2017, 3:13:03 PM  peteolcott
    https://groups.google.com/g/comp.theory/c/NcFS02hKs1U/m/PlBF-1LRBAAJ




    I actually inadvertently came up with it in this paper:
    Self Modifying Turing Machine (SMTM) Solution to the Halting Problem
    (concrete example)  August 2016

    Which shows you don't understand how Turing Machines work. Turing
    Machine have no way to 'access' there code to make the changes.


    I pointed to this paper as the origin of the key element of my current
    proof.

    Also, they don't NEED to change there code, they just need a
    'state-bit' to decide on each of the options they might be able to
    reprogram themselves with.

    Your description (from what I remember) actually needed an 'external
    agent' to actually make the sort of changes you wanted to do, and
    thus, you actually need to fold that external agent into the Turing
    Machine to make it back into an actual computation, and then it fails
    to have that 'magical' property of not being able to be 'outwitted'
    by a machine using it.

    FAIL.



    https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example


    No one has actually pointing out any error in the essence of what I
    have said:

    Simple English version of Olcott's Halt status criterion measure:
    Every simulating halt decider that must abort the simulation of its
    input to prevent its infinite simulation correctly transitions to
    its reject state.

    Which is the WRONG definition.


    It is an unconventional new definition that maps to the original
    definition thus is provably equivalent.


    Nope, not equivalent. If it WAS equivelent it would give the same answer
    for H^ applied to <H^>, which it doesn't.

    Shows you don't even know the meaning of 'Equivalent'

    They both define the same set of non-halting elements.

    --
    Copyright 2021 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 Thu Mar 3 22:33:46 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/3/2022 10:23 PM, Richard Damon wrote:
    On 3/3/22 10:39 PM, olcott wrote:
    On 3/3/2022 9:22 PM, Richard Damon wrote:

    On 3/3/22 10:05 PM, olcott wrote:
    On 3/3/2022 8:39 PM, Richard Damon wrote:
    On 3/3/22 9:05 PM, olcott wrote:
    On 3/3/2022 7:14 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/3/2022 5:56 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    This is not about rehashing old points this is about
    evaluating new
    points.
    The eternal refrain of the Usenet crank: talk to me about this new >>>>>>>>> nonsense; forget I ever said that old nonsense.
    My posts will be about whatever I want them to be about.  Of >>>>>>>>> course you
    will ignore all your old mistakes -- you ignored them when they >>>>>>>>> were new
    mistakes!

    I have proven that your rebuttals from six months ago are
    incorrect on
    the basis of a better analysis. It is OK if you want to chicken >>>>>>>> out,
    you are not my target audience.

    By my reckoning, you first claimed to have refuted every proof[1] of >>>>>>> this simple theorem over 17 years ago.  17 years.  How long can >>>>>>> on paper
    take to finish?


    I have to make my proof so clearly correct that it is fully
    understood before it is rejected out-of-hand on the basis of its
    subject matter.

    I still need to learn more about computable functions. None of the >>>>>> theory of computation textbooks go into the same depth that others >>>>>> here refer to. I was not sure that a RASP computable function
    could know its own machine address until André's explanation.

    So you ADMIT you don't know the basic meaning of things in the
    Theory, but you have made claims based on things that you claim are
    obvious by 'The meaning of the words' that include these terms.


    I did not know that a RASP function can know its own address and
    still be construed as a computation in computer science.


    The problem you are going to run into is that RASP machines don't
    have 'input' as generally constructed. This makes it harder to design
    a RASP machine that takes as an input the description of another
    arbitrary computation. (This is the same problem you 'H' program has).


    I have proven that I have refuted the halting problem proofs
    categorically. I only need to perfect my use of terminology.


    Not 'Perfect', first you need to learn the basics of the terminology.


    I know that all deciders compute the mapping from their input finite
    strings to an accept or reject state. You and Ben prove that you do
    not understand that halt deciders are deciders.


    I have never said anything against H being a decider, just that the
    function it computes is not the halting function.

    You keep on quoting some made up rule that somehow the behavior of H^
    applied to <H^> can't be the basis of the correct answer for H applied
    to <H^> <H^> since it isn't what the 'input' is.


    It is not any made up rule. You just proved that you have woefully
    insufficient understanding of deciders.

    When they compute the mapping from their input finite strings to an
    accept or reject state IT HAS TO BE THE ACTUAL FREAKING INPUT.


    --
    Copyright 2021 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 Mikko on Fri Mar 4 10:30:20 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/4/2022 4:43 AM, Mikko wrote:
    On 2022-03-03 14:58:15 +0000, olcott said:

    On 3/3/2022 4:34 AM, Mikko wrote:
    On 2022-03-03 03:13:35 +0000, olcott said:

    We make it even simpler a decider is required to compute the mapping
    from its finite string input to an accept or reject state.

    Irrelevant, as Linz' Definition 12.1 does not use the word "decider" and >>> does not require that the solution to the halting problem be a decider.

    Mikko


    All halt deciders are deciders.

    The definition 12.1 does not say so.

    Mikko


    It does not have to say this for this to be true.


    The term decider doesn't really have a standard meaning. In fact, it is lamentable that Sipser chose the terms decider and recognizer, since
    they seem to confuse students.

    Intuitively, a decider should be a Turing machine that given an input,
    halts and either accepts or rejects, relaying its answer in one of many equivalent ways, such as halting at an ACCEPT or REJECT state, or
    leaving its answer on the output tape. https://cs.stackexchange.com/questions/84433/what-is-decider

    In computability theory and computational complexity theory, a decision
    problem is a problem that can be posed as a yes–no question of the input values. https://en.wikipedia.org/wiki/Decision_problem

    In computability theory and computational complexity theory, an
    undecidable problem is a decision problem for which it is proved to be impossible to construct an algorithm that always leads to a correct
    yes-or-no answer. The halting problem is an example: it can be proven
    that there is no algorithm that correctly determines whether arbitrary
    programs eventually halt when run. https://en.wikipedia.org/wiki/Undecidable_problem

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Mar 4 10:43:50 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/4/2022 9:24 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/3/2022 7:14 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/3/2022 5:56 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    This is not about rehashing old points this is about evaluating new >>>>>> points.
    The eternal refrain of the Usenet crank: talk to me about this new
    nonsense; forget I ever said that old nonsense.
    My posts will be about whatever I want them to be about. Of course you >>>>> will ignore all your old mistakes -- you ignored them when they were new >>>>> mistakes!

    I have proven that your rebuttals from six months ago are incorrect on >>>> the basis of a better analysis. It is OK if you want to chicken out,
    you are not my target audience.

    By my reckoning, you first claimed to have refuted every proof[1] of
    this simple theorem over 17 years ago. 17 years. How long can on paper >>> take to finish?


    I have to make my proof so clearly correct that it is fully understood
    before it is rejected out-of-hand on the basis of its subject matter.

    Your recent work will be rejected out of hand if you are clear, because
    it will be clear that you are not talking about the halting problem. If
    you find a way of describing it that is so convoluted that it's not immediately clear, it will be rejected because it's too vague.

    It's possible that, as below, you accidentally do end up talking about
    the halting problem. Then your work will be rejected because that
    question is settled. In this case, to get out of the editor's joke
    pile, you would have to show a flaw in every proof, and you have not
    even read Linz's proof (the real one, not the one presented, rather
    sloppily in my opinion, for historical interest) let along all the
    others.

    Attacking proofs raises an even bigger problem for you: you don't know
    what a proof is. You still think that if {A} ⊦ X, then {A,~A} ⊬ X so there is really nothing you can do in terms of the existing proofs that
    won't be "joke pile" ready from the get-go.

    I still need to learn more about computable functions. None of the
    theory of computation textbooks go into the same depth that others
    here refer to.

    Have you actually read a book on this topic? There's no sign that you
    have. You didn't even know what a function was a few months ago.

    No one has actually pointing out any error in the essence of what I
    have said:

    At least three people have done exactly that. Many times. And quite a
    few more than three over the 17 years you've been trying to say
    something original on this topic. What you mean is that you ignore or
    don't understand the errors being pointed out to you.

    Simple English version of Olcott's Halt status criterion measure:
    Every simulating halt decider that must abort the simulation of its
    input to prevent its infinite simulation correctly transitions to its
    reject state.

    Let me point out the error yet again: this is not the halting problem.

    Somewhat formalized version of Olcott's Halt status criterion measure:
    Let ⟨M⟩ describe a Turing machine M = (Q, Σ, Γ, δ, q₀, □, F), and let
    w be any element of Σ⁺, A solution of the halting problem is a Turing
    machine H, which for any ⟨M⟩ and w, performs the computation (Linz
    1990:317)

    Writing "Linz 1990:317" make it look like you are quoting Linz, but this
    is not a direct quote.

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
    state of M

    "UTM(⟨M⟩, w) reaches the final state of M" if, and only if, "M halts on input w" so your conditions are correct, and the same as Linz's.

    This is the halting problem, pointlessly reworded in terms of a UTM so
    you should be able to write out the rest of the proof using the

    Of course, your rewording is technically wrong because you don't do
    details, but unless you want to be taken 100% literally at your word, I
    don't think they stop you being understood.

    But you don't want to be understood to be talking about Linz's simple conditions -- you want to talk about the problem with the "revised
    criteria" that is not the HP. That puts you in a bind. Talk about the
    HP and you have to find flaws in proofs you can't understand. Talk
    about your other problem, and no one will care.


    In computability theory, the halting problem is the problem of
    determining, from a description of an arbitrary computer program and an
    input, whether the program will finish running, or continue to run
    forever. https://en.wikipedia.org/wiki/Halting_problem

    Thus a halt decider would compute the mapping from its input finite
    strings to an accept or reject state on the basis of whether or not the
    finite string pair specifies a computation that halts.

    All sequences of configurations that never reach their final state are
    not computations that halt.

    When a sequence of configurations would never reach their final state in
    any finite number of steps of pure simulation then this sequence of configurations specify non-halting behavior.

    The criterion measure shown below defines the set of configurations that
    never reach their final state.

    Simple English version of Olcott's Halt status criterion measure:
    Every simulating halt decider that must abort the simulation of its
    input to prevent its infinite simulation correctly transitions to its
    reject state.


    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Mar 4 10:55:58 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    I know that all deciders compute the mapping from their input finite
    strings to an accept or reject state. You and Ben prove that you do
    not understand that halt deciders are deciders.

    Lying about technical matters is one thing[1], but lying about people is
    not on. It's despicable and you should stop doing it.


    When you would actually directly address the point at hand you have no
    rebuttal because it is correct.

    Thus you must always dodge the point at hand so that it superficially
    looks like you have provided a rebuttal to gullible fools that aren't
    hardly paying any attention.

    THIS IS THE POINT AT HAND
    It is the case that all deciders ONLY compute the mapping from their
    input finite strings to an accept or reject state thus everything that
    is not an input finite sting is out-of-scope for the decider.

    This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
    accept or reject state and is not allowed to report on the behavior of
    the computation that contains itself Ĥ ⟨Ĥ⟩.


    [1] To pick a couple out of many:

    "I provide the exact ⊢* wildcard states after the Linz H.q0 and after
    Ĥ.qx ... showing exactly how the actual Linz H would correctly decide
    the actual Linz (Ĥ, Ĥ)."

    "I now have an actual H that decides actual halting for an actual (Ĥ,
    Ĥ) input pair. I have to write the UTM to execute this code, that
    should not take very long. The key thing is the H and Ĥ are 100%
    fully encoded as actual Turing machines."



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Mar 4 12:12:45 2022
    XPost: comp.theory, sci.math, sci.logic

    On 3/4/2022 11:36 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    I know that all deciders compute the mapping from their input finite
    strings to an accept or reject state. You and Ben prove that you do
    not understand that halt deciders are deciders.
    Lying about technical matters is one thing[1], but lying about people is >>> not on. It's despicable and you should stop doing it.

    When you would actually directly address the point at hand you have no
    rebuttal because it is correct.

    What are you waffling about now? Of course a halt decider (were such a
    thing to exist) would be a decider. Your lie is that neither I nor
    Richard have ever said what claim. Continuing to lie about what people
    claim is despicable. You've done it before. You will probably keep
    doing it.

    THIS IS THE POINT AT HAND

    By which you mean this the current distraction from 17 years of
    uncorrected mistakes.

    It is the case that all deciders ONLY compute the mapping from their
    input finite strings to an accept or reject state thus everything that
    is not an input finite sting is out-of-scope for the decider.

    Apart form the bad wording, no one has ever objected to that.

    This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
    accept or reject state and is not allowed to report on the behavior of
    the computation that contains itself Ĥ ⟨Ĥ⟩.

    Nonsense. First off, this is a silly use of language -- a TM is not "allowed" or "not allowed" to do anything. A TM+input entails a
    sequence of configurations determined solely by the state transition
    function and the input. They have do not need permission for anything,
    and permission can not be withdrawn about anything.

    embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
    configurations up to qn or qy. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
    H accepts ⟨Ĥ⟩ ⟨Ĥ⟩. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.
    It seems that all you have is one dishonest dodge or another. I have not
    been speaking about H for many months so when you bring it up now it is
    a direct dodge of the point at hand.

    When embedded_H computes the mapping from its input finite string pair
    ⟨Ĥ⟩ ⟨Ĥ⟩ inputs to an accept or reject state it does this on the basis of
    the behavior specified by this finite string pair: ⟨Ĥ⟩ ⟨Ĥ⟩ and not on the basis of the behavior of the computation that contains itself: Ĥ ⟨Ĥ⟩.

    Your failure to understand this proves that you do not sufficiently
    understand how deciders work.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Mar 4 17:56:15 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/4/2022 5:30 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/4/2022 11:36 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    I know that all deciders compute the mapping from their input finite >>>>>> strings to an accept or reject state. You and Ben prove that you do >>>>>> not understand that halt deciders are deciders.
    Lying about technical matters is one thing[1], but lying about people is >>>>> not on. It's despicable and you should stop doing it.

    When you would actually directly address the point at hand you have no >>>> rebuttal because it is correct.
    What are you waffling about now? Of course a halt decider (were such a
    thing to exist) would be a decider. Your lie is that neither I nor
    Richard have ever said what claim. Continuing to lie about what people
    claim is despicable. You've done it before. You will probably keep
    doing it.

    THIS IS THE POINT AT HAND
    By which you mean this the current distraction from 17 years of
    uncorrected mistakes.

    It is the case that all deciders ONLY compute the mapping from their
    input finite strings to an accept or reject state thus everything that >>>> is not an input finite sting is out-of-scope for the decider.
    Apart form the bad wording, no one has ever objected to that.

    This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
    accept or reject state and is not allowed to report on the behavior of >>>> the computation that contains itself Ĥ ⟨Ĥ⟩.

    Nonsense. First off, this is a silly use of language -- a TM is not
    "allowed" or "not allowed" to do anything. A TM+input entails a
    sequence of configurations determined solely by the state transition
    function and the input. They have do not need permission for anything,
    and permission can not be withdrawn about anything.
    embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
    configurations up to qn or qy. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
    H accepts ⟨Ĥ⟩ ⟨Ĥ⟩. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.

    It seems that all you have is one dishonest dodge or another. I have
    not been speaking about H for many months so when you bring it up now
    it is a direct dodge of the point at hand.

    Of course you are not speaking about H. You are wrong about H so you
    must try to not talk about it anymore. Ironically it's you that want me
    to dodge this issue: if I can't talk about H, you condemn me to do
    nothing but dodge the key point -- that H is wrong.

    When embedded_H computes the mapping from its input finite string pair
    ⟨Ĥ⟩ ⟨Ĥ⟩ inputs to an accept or reject state it does this on the basis
    of the behavior specified by this finite string pair: ⟨Ĥ⟩ ⟨Ĥ⟩

    Sign. I wish you could get the details right. It would allow a
    discussion of the big mistakes. embedded_H has no accepting state.


    embedded_H does indeed have an accept state, Ĥ.qy still exists even
    though it has been broken by the appended infinite loop.

    Anyway, I can't tell you why you are wrong because I must not talk about
    H. Great -- that simplifies my replies a lot.

    and not on the basis of the behavior of the computation that contains
    itself: Ĥ ⟨Ĥ⟩.

    Fortunately for you, you have banned me from telling you why this is
    wrong!


    WHICH FACTS DO YOU DISAGREE WITH?
    (a) It is the case that deciders compute the mapping ONLY from their
    inputs to an accept or reject state.

    (b) It is the case that deciders DO NOT compute the mapping from
    non-inputs to anything.

    (c) It is the case that the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach the final state of ⟨Ĥ⟩.qn in any finite number of steps.

    Your failure to understand this proves that you do not sufficiently
    understand how deciders work.

    I know why you are wrong, but if I told you I would, apparently, be
    dodging something! Enjoy your ignorance. If it gets tedious, the offer
    to explain remains open...


    If my reasoning is incorrect then a flaw could be pointed out. If it is impossible to point out any error in my reasoning then this proves that
    it is correct.

    To avoid this challenge you simply change the subject to fool the
    gullible into believing that you provided a rebuttal. Gullible fools
    never notice that a rebuttal has no supporting reasoning as long as it
    does have seemingly convincing rhetoric.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Mar 4 18:34:13 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    When a sequence of configurations would never reach their final state
    in any finite number of steps of pure simulation then this sequence of
    configurations specify non-halting behavior.

    This is the halting problem. It is better expressed in the simpler
    terms given in texts like Linz. I don't like the wording, just gives
    the gist.


    OK good so far.

    The criterion measure shown below defines the set of configurations
    that never reach their final state.

    Simple English version of Olcott's Halt status criterion measure:
    Every simulating halt decider that must abort the simulation of its
    input to prevent its infinite simulation correctly transitions to its
    reject state.

    This is not the halting problem. Its even more badly written than the
    first (for example, it's circular, and uses undefined metaphors like
    "abort") but it conveys enough for readers to know that it's not the
    correct criterion for the halting problem. It's this "Halt status
    criterion measure" (pompous or what?) that permits your decider to
    reject a string that represents a halting computation.


    When a simulating halt decider correctly determines its correctly
    simulated input would never reach its final state in any finite number
    of steps of pure simulation then this simulating halt decider has
    correctly determined that this input specifies non-halting behavior.

    You need to pick what H is defined to do -- decide halting (as in Linz),
    or to decide PO-almost-but-not-really halting (which no one but you
    cares about). But it's clear from the above that are trying to
    equivocate -- its the same as halting, honest! -- just re-worded so it
    isn't.



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Sat Mar 5 15:26:56 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    When a sequence of configurations would never reach their final state
    in any finite number of steps of pure simulation then this sequence of >>>> configurations specify non-halting behavior.

    This is the halting problem. It is better expressed in the simpler
    terms given in texts like Linz. I don't like the wording, just gives
    the gist.

    OK good so far.

    The criterion measure shown below defines the set of configurations
    that never reach their final state.

    Simple English version of Olcott's Halt status criterion measure:
    Every simulating halt decider that must abort the simulation of its
    input to prevent its infinite simulation correctly transitions to its
    reject state.

    This is not the halting problem. Its even more badly written than the
    first (for example, it's circular, and uses undefined metaphors like
    "abort") but it conveys enough for readers to know that it's not the
    correct criterion for the halting problem. It's this "Halt status
    criterion measure" (pompous or what?) that permits your decider to
    reject a string that represents a halting computation.

    When a simulating halt decider correctly determines its correctly
    simulated input would never reach its final state in any finite number
    of steps of pure simulation then this simulating halt decider has
    correctly determined that this input specifies non-halting behavior.

    There is no such thing as a simulating halt decider because there are no
    halt deciders at all.

    Then call it a halt determiner.

    But we can find out what you are saying about
    these things asking if a TM, any TM, can do what you say:

    When a TM (any TM) correctly determines its correctly simulated input
    would never reach its final state in any finite number of steps of pure simulation then this TM has correctly determined that this input
    specifies non-halting behavior.

    And re-worded again using tighter language and without all the filler
    words:

    When a TM determines that a simulation of its input would not halt it
    can correctly report that the input represents a non-halting
    computation.


    Not precise enough. It must be a simulation performed by the simulating
    halt determiner.

    When a TM determines that [its correct pure] simulation of its input
    would not halt it can correctly report that the input represents a
    non-halting computation.

    Your definition will be to confusing for people that are not computer scientists because they will believe that when the simulating halt
    determiner aborts its simulation that this causes the input to halt,
    thus the halt determiner is contradicting itself.

    And even more simply (and obviously):

    When a TM determines that its input represents a non-halting computation
    it can correct report that the input represents a non-halting
    computation.

    Kind of pointless thing to say, isn't it? Such TMs are ten-a-penny.

    The irony is that you limited your claim (a safe and reasonable claim as
    I hope you can see) to the very class of TMs that /can't/ do what you
    say because there are none!


    A halt determiner is the same thing as a halt decider with the only
    difference being that the halt determiner needs to only correctly
    determine the halt status of a single input pair or a limited set of
    input pairs, thus has a restricted domain.

    When a simulating halt determiner correctly determines its correctly
    simulated input would never reach its final state in any finite number
    of steps of pure simulation then this simulating halt determiner has
    correctly determined that this input specifies non-halting behavior.

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

    Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
    ⟨Ĥ⟩.qn ?

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...




    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Sun Mar 6 13:17:08 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/6/2022 11:36 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    When a sequence of configurations would never reach their final state >>>>>> in any finite number of steps of pure simulation then this sequence of >>>>>> configurations specify non-halting behavior.

    This is the halting problem. It is better expressed in the simpler
    terms given in texts like Linz. I don't like the wording, just gives >>>>> the gist.

    OK good so far.

    The criterion measure shown below defines the set of configurations >>>>>> that never reach their final state.

    Simple English version of Olcott's Halt status criterion measure:
    Every simulating halt decider that must abort the simulation of its >>>>>> input to prevent its infinite simulation correctly transitions to its >>>>>> reject state.

    This is not the halting problem. Its even more badly written than the >>>>> first (for example, it's circular, and uses undefined metaphors like >>>>> "abort") but it conveys enough for readers to know that it's not the >>>>> correct criterion for the halting problem. It's this "Halt status
    criterion measure" (pompous or what?) that permits your decider to
    reject a string that represents a halting computation.

    When a simulating halt decider correctly determines its correctly
    simulated input would never reach its final state in any finite number >>>> of steps of pure simulation then this simulating halt decider has
    correctly determined that this input specifies non-halting behavior.
    There is no such thing as a simulating halt decider because there are no >>> halt deciders at all.

    Then call it a halt determiner.

    What they are called is not really very important. What they do is
    crucial.

    But we can find out what you are saying about
    these things asking if a TM, any TM, can do what you say:

    When a TM (any TM) correctly determines its correctly simulated input
    would never reach its final state in any finite number of steps of pure
    simulation then this TM has correctly determined that this input
    specifies non-halting behavior.

    And re-worded again using tighter language and without all the filler
    words:

    When a TM determines that a simulation of its input would not halt it
    can correctly report that the input represents a non-halting
    computation.

    Not precise enough. It must be a simulation performed by the
    simulating halt determiner.

    Ah, then you need to define what that is. If it's different to a
    simulator in any significant way then your statements is not about the halting problem and can be ignored.

    When a TM determines that [its correct pure] simulation of its input
    would not halt it can correctly report that the input represents a
    non-halting computation.

    This is either the same as my re-write (if you remove the [...] part or replace "its" with "a") or it is an attempt to obscure the that fact
    that the "determiner" can ignore some halting computations because "it" halted them. I am sure it the latter this as been you ruse for ages.

    Anyway, you should either write the correct condition as found in every textbook you've never read, or just come clean that you are not talking
    about the halting problem.

    Your definition will be to confusing for people that are not computer
    scientists because they will believe that when the simulating halt
    determiner aborts its simulation that this causes the input to halt,
    thus the halt determiner is contradicting itself.

    My definition did not use undefined terms like "simulating halt
    determiner" or "abort". And mine had no absurd vague "its" in it.

    And even more simply (and obviously):
    When a TM determines that its input represents a non-halting computation >>> it can correct report that the input represents a non-halting
    computation.

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

    Of course you miss of the key conditions because you have not yet found
    a way to write the that fools anyone:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.

    Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
    ⟨Ĥ⟩.qn ?

    Who knows? You have not defined what ⟨Ĥ⟩.qn means. In Linz, embedded_H is the same as H (with a few tweaks) and can't correctly transition to
    either Ĥ.qn or Ĥ.qy.

    Your embedded_H is a mystery because it's not as in Linz.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    OK. You are permitted to say that that is what you Ĥ does. Why should anyone care?



    A halt determiner is the same thing as a halt decider with the only
    difference being that the halt determiner needs to only correctly
    determine the halt status of a single input pair or a limited set of
    input pairs thus has a restricted domain.

    A simulating halt determiner determines whether or not its input
    specifies a non-halting sequence of configurations on the basis of
    recognizing infinite patterns in the behavior of its simulated input
    (such as the above pattern) that indicate that it would never reach its
    final state in any finite number of steps of pure simulation.

    Why should anyone care?


    Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its
    input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this is
    impossible.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Sun Mar 6 18:53:47 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/6/2022 6:21 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/6/2022 11:36 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    When a sequence of configurations would never reach their final state >>>>>>>> in any finite number of steps of pure simulation then this sequence of >>>>>>>> configurations specify non-halting behavior.

    This is the halting problem. It is better expressed in the simpler >>>>>>> terms given in texts like Linz. I don't like the wording, just gives >>>>>>> the gist.

    OK good so far.

    The criterion measure shown below defines the set of configurations >>>>>>>> that never reach their final state.

    Simple English version of Olcott's Halt status criterion measure: >>>>>>>> Every simulating halt decider that must abort the simulation of its >>>>>>>> input to prevent its infinite simulation correctly transitions to its >>>>>>>> reject state.

    This is not the halting problem. Its even more badly written than the >>>>>>> first (for example, it's circular, and uses undefined metaphors like >>>>>>> "abort") but it conveys enough for readers to know that it's not the >>>>>>> correct criterion for the halting problem. It's this "Halt status >>>>>>> criterion measure" (pompous or what?) that permits your decider to >>>>>>> reject a string that represents a halting computation.

    When a simulating halt decider correctly determines its correctly
    simulated input would never reach its final state in any finite number >>>>>> of steps of pure simulation then this simulating halt decider has
    correctly determined that this input specifies non-halting behavior. >>>>> There is no such thing as a simulating halt decider because there are no >>>>> halt deciders at all.

    Then call it a halt determiner.
    What they are called is not really very important. What they do is
    crucial.

    But we can find out what you are saying about
    these things asking if a TM, any TM, can do what you say:

    When a TM (any TM) correctly determines its correctly simulated input >>>>> would never reach its final state in any finite number of steps of pure >>>>> simulation then this TM has correctly determined that this input
    specifies non-halting behavior.

    And re-worded again using tighter language and without all the filler >>>>> words:

    When a TM determines that a simulation of its input would not halt it >>>>> can correctly report that the input represents a non-halting
    computation.

    Not precise enough. It must be a simulation performed by the
    simulating halt determiner.

    Ah, then you need to define what that is. If it's different to a
    simulator in any significant way then your statements is not about the
    halting problem and can be ignored.

    This is me pointing out a mistake which you are, as usual, ignoring.
    Soon you will say, again, that no one can point out any errors in what
    you say.


    Since I have defined it 10,000 times it seems a little nuts that you ask
    me to define it again. I have defined it again below.

    When a TM determines that [its correct pure] simulation of its input
    would not halt it can correctly report that the input represents a
    non-halting computation.

    This is either the same as my re-write (if you remove the [...] part or
    replace "its" with "a") or it is an attempt to obscure the that fact
    that the "determiner" can ignore some halting computations because "it"
    halted them. I am sure it the latter this as been you ruse for ages.
    Anyway, you should either write the correct condition as found in every
    textbook you've never read, or just come clean that you are not talking
    about the halting problem.

    This is me pointing out another two mistakes which you are, as usual, ignoring. Soon you will say, again, that no one can point out any
    errors in what you say.


    When-so-ever a simulating halt determiner detects an infinite behavior
    pattern in the simulation of its input such that this simulated input
    would never reach its final state in any finite number of steps it
    rejects this input.

    Your definition will be to confusing for people that are not computer
    scientists because they will believe that when the simulating halt
    determiner aborts its simulation that this causes the input to halt,
    thus the halt determiner is contradicting itself.
    My definition did not use undefined terms like "simulating halt
    determiner" or "abort". And mine had no absurd vague "its" in it.

    And this is me pointing out yet another mistake which you are, as usual, ignoring. Soon you will say, again, that no one can point out any
    errors in what you say.


    It is freaking nuts to require "simulation has been aborted" to be defined.


    And even more simply (and obviously):
    When a TM determines that its input represents a non-halting computation >>>>> it can correct report that the input represents a non-halting
    computation.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    Of course you miss of the key conditions because you have not yet found
    a way to write the that fools anyone:
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.

    Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
    ⟨Ĥ⟩.qn ?
    Who knows? You have not defined what ⟨Ĥ⟩.qn means.

    And this is me pointing out yet another mistake which you are, as usual, ignoring. Soon you will say, again, that no one can point out any
    errors in your reasoning.

    When this simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ has reached its own final state this
    final state is referred to as ⟨Ĥ⟩.qn.

    In Linz, embedded_H
    is the same as H (with a few tweaks) and can't correctly transition to
    either Ĥ.qn or Ĥ.qy.
    Your embedded_H is a mystery because it's not as in Linz.

    And this is me pointing out yet another mistake which you are, as usual, ignoring.

    embedded_H is the copy of H that Linz specifies is embedded in the
    middle of Ĥ (as I have repeated dozens of times).

    Do you always expect me to repeat every single detail on every single post?

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
    OK. You are permitted to say that that is what you Ĥ does. Why should >>> anyone care?

    A halt determiner is the same thing as a halt decider with the only
    difference being that the halt determiner needs to only correctly
    determine the halt status of a single input pair or a limited set of
    input pairs thus has a restricted domain.

    Then, for every single "input pair", there are an infinity of correct
    "halt determiners". No one is interested in such trivial things.

    You will probably be baffled by how I can say this, but I bet that, if
    your are, you won't try to find out by trying to learn something.

    A simulating halt determiner determines whether or not its input
    specifies a non-halting sequence of configurations on the basis of
    recognizing infinite patterns in the behavior of its simulated input
    (such as the above pattern) that indicate that it would never reach
    its final state in any finite number of steps of pure simulation.

    That's one way to write some of these trivial Turing machines. I still
    don't care about them.


    The simulating halt determiner that decides halting for the Linz Ĥ
    defeats his proof.

    Why should anyone care?

    Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its
    input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this
    is impossible.

    Linz's H does not exist. There is no input string ⟨Ĥ⟩ ⟨Ĥ⟩. There is a
    proof about that. There are lots of proofs about that.

    Your H may exist, but it's not Linz's.

    As long as the Linz Ĥ relationship to its halt determiner is maintained
    any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never halts defeats the Linz proof.


    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Sun Mar 6 21:16:34 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
    I'm getting bored so I will skip to the chase at the end..

    olcott <NoOne@NoWhere.com> writes:

    On 3/6/2022 6:21 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    A halt determiner is the same thing as a halt decider with the only
    difference being that the halt determiner needs to only correctly
    determine the halt status of a single input pair or a limited set of
    input pairs thus has a restricted domain.

    Then, for every single "input pair", there are an infinity of correct
    "halt determiners". No one is interested in such trivial things.

    You will probably be baffled by how I can say this, but I bet that, if
    your are, you won't try to find out by trying to learn something.

    A simulating halt determiner determines whether or not its input
    specifies a non-halting sequence of configurations on the basis of
    recognizing infinite patterns in the behavior of its simulated input
    (such as the above pattern) that indicate that it would never reach
    its final state in any finite number of steps of pure simulation.

    That's one way to write some of these trivial Turing machines. I still
    don't care about them.

    The simulating halt determiner that decides halting for the Linz Ĥ
    defeats his proof.

    No. You have not noticed what you have actually said, have you?

    Why should anyone care?

    Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its >>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this
    is impossible.

    Linz's H does not exist. There is no input string ⟨Ĥ⟩ ⟨Ĥ⟩. There is a
    proof about that. There are lots of proofs about that.
    Your H may exist, but it's not Linz's.

    As long as the Linz Ĥ relationship to its halt determiner is
    maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
    halts defeats the Linz proof.

    Not "any damn thing", no. It must be the supposed halt determiner, H,
    that correctly determines it. Now that might be what you are trying to
    so say with the mysterious "its", but then putting in "any damn thing"
    is just daft.

    More clearly, if you have an TM H such that either

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,

    or

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,

    then you will have done the impossible thing what you claimed to have
    done more than three years ago.

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

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    Because the pure simulation of the ⟨Ĥ⟩ ⟨Ĥ⟩ input to the simulating halt
    determiner at Ĥ.qx would never reach its own final state of ⟨Ĥ⟩.qn in
    any finite number of steps this input is correctly rejected.



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Mon Mar 7 09:14:00 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
    I'm getting bored so I will skip to the chase at the end..
    olcott <NoOne@NoWhere.com> writes:

    As long as the Linz Ĥ relationship to its halt determiner is
    maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
    halts defeats the Linz proof.

    Not "any damn thing", no. It must be the supposed halt determiner, H,
    that correctly determines it. Now that might be what you are trying to
    so say with the mysterious "its", but then putting in "any damn thing"
    is just daft.

    More clearly, if you have an TM H such that either
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
    then you will have done the impossible thing what you claimed to have
    done more than three years ago.

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

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    So, just to be 100% clear, you are /not/ claiming to have an TM that
    does either


    What I am claiming is that the above shows that if embedded_H rejected
    its input it would be correct.

    Because the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never
    reach its own final state of ⟨Ĥ⟩.qn in any finite number of steps of simulation embedded_H would be correct to reject its input: ⟨Ĥ⟩ ⟨Ĥ⟩

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩

    You did once and, since it's impossible, it hooked people in.

    I have not been talking about H for many months. I have been talking
    about the simulating halt determiner at Ĥ.qx that I refer to as embedded_H.

    https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Mon Mar 7 12:42:25 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
    I'm getting bored so I will skip to the chase at the end..
    olcott <NoOne@NoWhere.com> writes:

    As long as the Linz Ĥ relationship to its halt determiner is
    maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
    halts defeats the Linz proof.

    Not "any damn thing", no. It must be the supposed halt determiner, H, >>>>> that correctly determines it. Now that might be what you are trying to >>>>> so say with the mysterious "its", but then putting in "any damn thing" >>>>> is just daft.

    More clearly, if you have an TM H such that either
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, >>>>> or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
    then you will have done the impossible thing what you claimed to have >>>>> done more than three years ago.

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

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    So, just to be 100% clear, you are /not/ claiming to have an TM that
    does either

    What I am claiming is that the above shows that if embedded_H rejected
    its input it would be correct.

    So what? We are interested in the halting problem and your claim to
    have addressed the key case: to have an H such that either


    The copy of Linz H embedded at Ĥ.qx would correctly decide that its
    input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this is
    impossible.

    https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
    in a finite number of steps.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
    state in any finite number of steps.



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Mon Mar 7 13:26:53 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
    I'm getting bored so I will skip to the chase at the end..
    olcott <NoOne@NoWhere.com> writes:

    As long as the Linz Ĥ relationship to its halt determiner is
    maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
    halts defeats the Linz proof.

    Not "any damn thing", no. It must be the supposed halt determiner, H, >>>>>>> that correctly determines it. Now that might be what you are trying to >>>>>>> so say with the mysterious "its", but then putting in "any damn thing" >>>>>>> is just daft.

    More clearly, if you have an TM H such that either
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
    then you will have done the impossible thing what you claimed to have >>>>>>> done more than three years ago.

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

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    So, just to be 100% clear, you are /not/ claiming to have an TM that >>>>> does either

    What I am claiming is that the above shows that if embedded_H rejected >>>> its input it would be correct.

    So what? We are interested in the halting problem and your claim to
    have addressed the key case: to have an H such that either

    The copy of Linz H embedded at Ĥ.qx would correctly decide that its
    input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
    is impossible.

    No. Linz's H is such that neither

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    nor
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,

    is possible.


    Like I said I am not talking about H.
    I have not been talking about H for many months.

    Also the key thing that you make sure to ignore is that it is never the
    case that any decider reports on the behavior of the computation that
    contains itself. Decider's are not capable of reporting on the behavior
    of Turing machines they can only accept or reject finite string inputs.

    https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
    in a finite number of steps.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
    state in any finite number of steps.

    Still don't care about this H of yours. You hooked people in with a lie
    that you kept repeating: your H is Linz's H. At least you've come clean
    now and are attempting a hand-waving definition of your H.



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Mon Mar 7 17:14:05 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/7/2022 5:05 PM, Ben Bacarisse wrote:
    Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

    On 07/03/2022 22:13, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
    I'm getting bored so I will skip to the chase at the end.. >>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:

    As long as the Linz Ĥ relationship to its halt determiner is >>>>>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
    halts defeats the Linz proof.

    Not "any damn thing", no. It must be the supposed halt determiner, H,
    that correctly determines it. Now that might be what you are trying to
    so say with the mysterious "its", but then putting in "any damn thing"
    is just daft.

    More clearly, if you have an TM H such that either
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
    then you will have done the impossible thing what you claimed to have
    done more than three years ago.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    So, just to be 100% clear, you are /not/ claiming to have an TM that >>>>>>>>> does either

    What I am claiming is that the above shows that if embedded_H rejected >>>>>>>> its input it would be correct.

    So what? We are interested in the halting problem and your claim to >>>>>>> have addressed the key case: to have an H such that either

    The copy of Linz H embedded at Ĥ.qx would correctly decide that its >>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
    is impossible.
    No. Linz's H is such that neither
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    nor
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
    is possible.

    Like I said I am not talking about H.
    I have not been talking about H for many months.
    There's no need to keep repeating that. I understand 100% that you are
    not talking about, and don't want to talk about, your H.

    When PO says "not talking about H" does that mean "not talking about
    PO's H" as you're thinking, or does it mean "not talking about Linz's
    H - I'm talking about Linz's Ĥ which contains a /copy/ of H that I'm
    calling embedded_H" ?

    I think it's both. He's walking a tightrope: if it is too obvious that
    what he calls H is not Linz's H, the game will be up. But if he is
    explicit that he means H as Linz does, the game is also up!


    The only difference between embedded_H and a copy of the Linz H is that embedded_H is not an ALL KNOWING halt decider it is merely a simulating
    halt determiner that correctly determines that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never
    halts, thus refuting the Linz proof that says this is impossible.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Mon Mar 7 17:07:11 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/7/2022 4:13 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
    I'm getting bored so I will skip to the chase at the end..
    olcott <NoOne@NoWhere.com> writes:

    As long as the Linz Ĥ relationship to its halt determiner is >>>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
    halts defeats the Linz proof.

    Not "any damn thing", no. It must be the supposed halt determiner, H,
    that correctly determines it. Now that might be what you are trying to
    so say with the mysterious "its", but then putting in "any damn thing"
    is just daft.

    More clearly, if you have an TM H such that either
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
    then you will have done the impossible thing what you claimed to have >>>>>>>>> done more than three years ago.

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

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    So, just to be 100% clear, you are /not/ claiming to have an TM that >>>>>>> does either

    What I am claiming is that the above shows that if embedded_H rejected >>>>>> its input it would be correct.

    So what? We are interested in the halting problem and your claim to >>>>> have addressed the key case: to have an H such that either

    The copy of Linz H embedded at Ĥ.qx would correctly decide that its
    input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
    is impossible.
    No. Linz's H is such that neither
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, >>> nor
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
    is possible.

    Like I said I am not talking about H.
    I have not been talking about H for many months.

    There's no need to keep repeating that. I understand 100% that you are
    not talking about, and don't want to talk about, your H.

    If you really don't want to talk about your H, don't reply. I'll say
    what I like about it in peace. But you can't offer any response to my
    posts about it if you won't talk about it.


    I am only talking about the simulating halt decider that is embedded in
    the middle of the Linz Ĥ at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

    Also the key thing that you make sure to ignore is that it is never
    the case that any decider reports on the behavior of the computation
    that contains itself. Decider's are not capable of reporting on the
    behavior of Turing machines they can only accept or reject finite
    string inputs.

    I don't ignore it, I tell you that you are wrong -- every time you bring
    it up. What's more, I have, on multiple occasions, said that I can
    offer you a series of exercises that, if you were to take them
    seriously, might lead you to see why you are wrong.

    This is one of your favourite themes. You accuse people of ignoring something that they have answered every time you bring it up. But,
    unlike a crank, I will answer it every time you ask: you are wrong. Of course deciders are capable of reporting on the behaviour of Turing
    machines.

    https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
    in a finite number of steps.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
    state in any finite number of steps.

    Still don't care about this H of yours. You hooked people in with a lie >>> that you kept repeating: your H is Linz's H. At least you've come clean >>> now and are attempting a hand-waving definition of your H.

    So the situation is

    That you cannot pay attention to the fact that when the simulating halt
    decider embedded within Linz Ĥ at Ĥ.qx would reject its input it would
    be correct and refute the Linz proof.

    https://www.liarparadox.org/Linz_Proof.pdf

    that no one cares about your H and you dare not talk
    about it! There is nothing substantive to discuss if you won't talk
    about the big mistakes.


    This is verbatim Linz except it has been adapted to my clearer
    notational conventions:

    <Linz quote>
    Now Ĥ is a Turing machine, so that it will have some description in
    Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ can also be used as input string. We can therefore legitimately ask what
    would happen if Ĥ is applied to ⟨Ĥ⟩.

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

    if Ĥ applied to ⟨Ĥ⟩ halts, and

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

    if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The contradiction tells us that our assumption of the existence of H, and
    hence the assumption of the decidability of the halting problem, must be
    false.
    </Linz quote>

    The copy of Linz H embedded at Ĥ.qx will be referred to as embedded_H

    Linz is confused into believing that embedded_H is reporting on the
    behavior of the computation that contains itself Ĥ applied to ⟨Ĥ⟩,
    rather than the behavior specified by its input: ⟨Ĥ⟩, ⟨Ĥ⟩.

    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS

    It is never the case that any decider reports on the behavior of the computation that contains itself. Deciders are not capable of reporting
    on the behavior of Turing machines they can only accept or reject finite
    string inputs.


    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Mon Mar 7 21:29:23 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 4:13 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
    I'm getting bored so I will skip to the chase at the end.. >>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:

    As long as the Linz Ĥ relationship to its halt determiner is >>>>>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
    halts defeats the Linz proof.

    Not "any damn thing", no. It must be the supposed halt determiner, H,
    that correctly determines it. Now that might be what you are trying to
    so say with the mysterious "its", but then putting in "any damn thing"
    is just daft.

    More clearly, if you have an TM H such that either
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
    then you will have done the impossible thing what you claimed to have
    done more than three years ago.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    So, just to be 100% clear, you are /not/ claiming to have an TM that >>>>>>>>> does either

    What I am claiming is that the above shows that if embedded_H rejected >>>>>>>> its input it would be correct.

    So what? We are interested in the halting problem and your claim to >>>>>>> have addressed the key case: to have an H such that either

    The copy of Linz H embedded at Ĥ.qx would correctly decide that its >>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
    is impossible.
    No. Linz's H is such that neither
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    nor
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
    is possible.

    Like I said I am not talking about H.
    I have not been talking about H for many months.
    There's no need to keep repeating that. I understand 100% that you are
    not talking about, and don't want to talk about, your H.
    If you really don't want to talk about your H, don't reply. I'll say
    what I like about it in peace. But you can't offer any response to my
    posts about it if you won't talk about it.

    I am only talking about the simulating halt decider that is embedded
    in the middle of the Linz Ĥ at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

    Oh, you are talking about Linz's H and Ĥ. OK. To "refute the proof"
    (as you put it) you'd need a TM that that does either

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩

    But you don't (though you once said you did). Unsurprisingly, the proof
    is solid. Such an H is impossible.

    Also the key thing that you make sure to ignore is that it is never
    the case that any decider reports on the behavior of the computation
    that contains itself. Decider's are not capable of reporting on the
    behavior of Turing machines they can only accept or reject finite
    string inputs.

    I don't ignore it, I tell you that you are wrong -- every time you bring >>> it up. What's more, I have, on multiple occasions, said that I can
    offer you a series of exercises that, if you were to take them
    seriously, might lead you to see why you are wrong.
    This is one of your favourite themes. You accuse people of ignoring
    something that they have answered every time you bring it up. But,
    unlike a crank, I will answer it every time you ask: you are wrong. Of
    course deciders are capable of reporting on the behaviour of Turing
    machines.

    So are you not interested in this fundamental error anymore? I suppose
    you need to wait a bit before saying I'm ignoring this point again!

    https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
    in a finite number of steps.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
    state in any finite number of steps.

    Still don't care about this H of yours. You hooked people in with a lie >>>>> that you kept repeating: your H is Linz's H. At least you've come clean >>>>> now and are attempting a hand-waving definition of your H.
    So the situation is

    That you cannot pay attention to the fact that when the simulating
    halt decider embedded within Linz Ĥ at Ĥ.qx would reject its input it
    would be correct and refute the Linz proof.

    No. To "refute the proof" you need an H that does either

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩

    but you won't even talk about H!

    Anyway, with cranks, silence is often the only answer one can get, so I
    can do no more than take your silence on this point as consent: you have
    no such TM and never did.

    After all, you've spent years walking back this claim, to the extent
    that you were recently touting a decider for some made up problem of
    your own that is not the halting problem.

    that no one cares about your H and you dare not talk
    about it! There is nothing substantive to discuss if you won't talk
    about the big mistakes.


    This is verbatim Linz except it has been adapted to my clearer
    notational conventions:

    <Linz quote>
    Now Ĥ is a Turing machine, so that it will have some description
    in Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ
    can also be used as input string. We can therefore legitimately ask
    what would happen if Ĥ is applied to ⟨Ĥ⟩.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>
    if Ĥ applied to ⟨Ĥ⟩ halts, and

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

    if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
    contradiction tells us that our assumption of the existence of H, and
    hence the assumption of the decidability of the halting problem, must
    be false.
    </Linz quote>

    The copy of Linz H embedded at Ĥ.qx will be referred to as embedded_H

    Linz is confused into believing that embedded_H is reporting on the
    behavior of the computation that contains itself Ĥ applied to ⟨Ĥ⟩,
    rather than the behavior specified by its input: ⟨Ĥ⟩, ⟨Ĥ⟩.

    No he is not. No mention at all is made of what embedded_H reports.
    The nonsense is simply that

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

    Your only hope of removing this contradiction is to change the
    conditions on those lines. That's the ruse you've been trying to pull
    for months with your pompous "Halt status criterion measure", but I
    suppose you've realised that won't wash so, at least for today, we are
    back to Linz's H and his correct criterion: halting.

    But there was a time you made a bolder claim: to have an H that gave the correct answer for this one case -- a TM that does either

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, or
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.

    But you no longer make that (impossible) claim.

    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS

    That you act like an over-tired six year old? I do try to ignore that.

    It is never the case that any decider reports on the behavior of the
    computation that contains itself. Deciders are not capable of
    reporting on the behavior of Turing machines they can only accept or
    reject finite string inputs.

    I keep addressing this. Again: you are wrong, Deciders /are/ capable of reporting on the behavior of Turing machines.

    Deciders only compute the mapping from input finite strings to accept or
    reject states. If you disagree please provide a link that proves that
    deciders compute mappings from non-input non-strings.

    If you don't disagree then you know that embedded_H does not compute the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).





    --
    Copyright 2021 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 Tue Mar 8 07:00:15 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/7/2022 9:57 PM, Richard Damon wrote:
    On 3/7/22 10:29 PM, olcott wrote:
    On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 4:13 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
    I'm getting bored so I will skip to the chase at the end.. >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:

    As long as the Linz Ĥ relationship to its halt determiner is >>>>>>>>>>>>>> maintained any damn thing that correctly determines that >>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ never
    halts defeats the Linz proof.

    Not "any damn thing", no.  It must be the supposed halt >>>>>>>>>>>>> determiner, H,
    that correctly determines it.  Now that might be what you >>>>>>>>>>>>> are trying to
    so say with the mysterious "its", but then putting in "any >>>>>>>>>>>>> damn thing"
    is just daft.

    More clearly, if you have an TM H such that either
            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
    or
            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on
    input ⟨Ĥ⟩,
    then you will have done the impossible thing what you >>>>>>>>>>>>> claimed to have
    done more than three years ago.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
    When Ĥ is applied to ⟨Ĥ⟩
           Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H
    simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
           Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H
    simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
           Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H
    simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
           Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H
    simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    So, just to be 100% clear, you are /not/ claiming to have an >>>>>>>>>>> TM that
    does either

    What I am claiming is that the above shows that if embedded_H >>>>>>>>>> rejected
    its input it would be correct.

    So what?  We are interested in the halting problem and your >>>>>>>>> claim to
    have addressed the key case: to have an H such that either

    The copy of Linz H embedded at Ĥ.qx would correctly decide that its >>>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says
    this
    is impossible.
    No.  Linz's H is such that neither
            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
    nor
            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩,
    is possible.

    Like I said I am not talking about H.
    I have not been talking about H for many months.
    There's no need to keep repeating that.  I understand 100% that you >>>>> are
    not talking about, and don't want to talk about, your H.
    If you really don't want to talk about your H, don't reply.  I'll say >>>>> what I like about it in peace.  But you can't offer any response to my >>>>> posts about it if you won't talk about it.

    I am only talking about the simulating halt decider that is embedded
    in the middle of the Linz Ĥ at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

    Oh, you are talking about Linz's H and Ĥ.  OK.  To "refute the proof" >>> (as you put it) you'd need a TM that that does either

            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
    or
            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩

    But you don't (though you once said you did).  Unsurprisingly, the proof >>> is solid.  Such an H is impossible.

    Also the key thing that you make sure to ignore is that it is never >>>>>> the case that any decider reports on the behavior of the computation >>>>>> that contains itself. Decider's are not capable of reporting on the >>>>>> behavior of Turing machines they can only accept or reject finite
    string inputs.

    I don't ignore it, I tell you that you are wrong -- every time you
    bring
    it up.  What's more, I have, on multiple occasions, said that I can >>>>> offer you a series of exercises that, if you were to take them
    seriously, might lead you to see why you are wrong.
    This is one of your favourite themes.  You accuse people of ignoring >>>>> something that they have answered every time you bring it up.  But, >>>>> unlike a crank, I will answer it every time you ask: you are
    wrong.  Of
    course deciders are capable of reporting on the behaviour of Turing
    machines.

    So are you not interested in this fundamental error anymore?  I suppose >>> you need to wait a bit before saying I'm ignoring this point again!

    https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final
    state
    in a finite number of steps.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own
    final
    state in any finite number of steps.

    Still don't care about this H of yours.  You hooked people in
    with a lie
    that you kept repeating: your H is Linz's H.  At least you've
    come clean
    now and are attempting a hand-waving definition of your H.
    So the situation is

    That you cannot pay attention to the fact that when the simulating
    halt decider embedded within Linz Ĥ at Ĥ.qx would reject its input it >>>> would be correct and refute the Linz proof.

    No.  To "refute the proof" you need an H that does either

            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
    or
            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩

    but you won't even talk about H!

    Anyway, with cranks, silence is often the only answer one can get, so I
    can do no more than take your silence on this point as consent: you have >>> no such TM and never did.

    After all, you've spent years walking back this claim, to the extent
    that you were recently touting a decider for some made up problem of
    your own that is not the halting problem.

    that no one cares about your H and you dare not talk
    about it!  There is nothing substantive to discuss if you won't talk >>>>> about the big mistakes.


    This is verbatim Linz except it has been adapted to my clearer
    notational conventions:

    <Linz quote>
         Now Ĥ is a Turing machine, so that it will have some description >>>> in Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ
    can also be used as input string. We can therefore legitimately ask
    what would happen if Ĥ is applied to ⟨Ĥ⟩.

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

    if Ĥ applied to  ⟨Ĥ⟩ halts, and

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

    if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The >>>> contradiction tells us that our assumption of the existence of H, and
    hence the assumption of the decidability of the halting problem, must
    be false.
    </Linz quote>

    The copy of Linz H embedded at Ĥ.qx will be referred to as embedded_H >>>>
    Linz is confused into believing that embedded_H is reporting on the
    behavior of the computation that contains itself Ĥ applied to ⟨Ĥ⟩, >>>> rather than the behavior specified by its input: ⟨Ĥ⟩, ⟨Ĥ⟩.

    No he is not.  No mention at all is made of what embedded_H reports.
    The nonsense is simply that

       Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞     if Ĥ applied to ⟨Ĥ⟩ halts, and >>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if Ĥ applied to ⟨Ĥ⟩ does not halt. >>>
    Your only hope of removing this contradiction is to change the
    conditions on those lines.  That's the ruse you've been trying to pull
    for months with your pompous "Halt status criterion measure", but I
    suppose you've realised that won't wash so, at least for today, we are
    back to Linz's H and his correct criterion: halting.

    But there was a time you made a bolder claim: to have an H that gave the >>> correct answer for this one case -- a TM that does either

            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
    or
            H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩.

    But you no longer make that (impossible) claim.

    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS
    THE KEY THING THAT YOU KEEP IGNORING IS

    That you act like an over-tired six year old?  I do try to ignore that. >>>
    It is never the case that any decider reports on the behavior of the
    computation that contains itself. Deciders are not capable of
    reporting on the behavior of Turing machines they can only accept or
    reject finite string inputs.

    I keep addressing this.  Again: you are wrong, Deciders /are/ capable of >>> reporting on the behavior of Turing machines.

    Deciders only compute the mapping from input finite strings to accept
    or reject states. If you disagree please provide a link that proves
    that deciders compute mappings from non-input non-strings.

    If you don't disagree then you know that embedded_H does not compute
    the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does >> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).



    You do like your Herring Red don't you.

    NO ONE says that the decider maps something that isn't its input.

    H applied to <H^> <H^> needs to figure out what its input maps to.

    I keep telling you and you keep forgetting that I have not been talking
    about H for many months. The copy of H at embedded at Ĥ.qx is not the
    same as H.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    The above repeating pattern shows that the correctly simulated input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively proving that this simulated input never halts. This enables embedded_H
    to abort its simulation and correctly transition to Ĥ.qn.

    The end result of this is embedded_H does correctly decide that its
    input ⟨Ĥ⟩ ⟨Ĥ⟩ halts thus refuting the Linz proof that says this is impossible.


    --
    Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
    Genius hits a target no one else can see." Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Tue Mar 8 07:06:16 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/8/2022 5:36 AM, Ben Bacarisse wrote:
    Mikko <mikko.levanto@iki.fi> writes:

    On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:

    Mikko <mikko.levanto@iki.fi> writes:

    On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:

    The words used don't alter the facts -- that there is no TM
    satisfying Linz's 12.1 can be, loosely, stated as "there is no
    decider for the strings that represent halting computations".
    Words can be (and often are) used to hide facts.
    But not, as far as I can see, in this case. The meaning of "decider" -- >>> a TM whose language is decidable -- is not causing any confusion. OK,
    PO lies about what other people say and/or know about "deciders", but
    the fault there is in the lying, not in the words used.

    In this case the probable intent was to argue about an irrelevance in
    order to draw attention from the fact that the presented soulution does
    not satisfy the definitiopn (21.1) of a solution to the halting
    problem.

    That's possible.


    I conclusively proved that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ never reaches its final state of ⟨Ĥ⟩.qn thus proving that embedded_H
    would be correct to reject its input. This refutes the Linz proof that concludes this is impossible.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Tue Mar 8 20:51:48 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/8/2022 7:14 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    It is never the case that any decider reports on the behavior of the
    computation that contains itself. Deciders are not capable of
    reporting on the behavior of Turing machines they can only accept or
    reject finite string inputs.

    I keep addressing this. Again: you are wrong, Deciders /are/ capable of >>> reporting on the behavior of Turing machines.

    Deciders only compute the mapping from input finite strings to accept
    or reject states.

    Of course. No one has ever disputed this obvious fact. (You only
    discovered it recently since you used to reject any talk on string
    encoding as an "extraneous detail", but now this "extraneous detail"
    gets top billing.)

    I will repeat my offer: if you would like to learn how "deciders compute
    only a function from input strings to accept/reject states" and
    "deciders /are/ capable of reporting on the behavior of Turing machines"
    are not contradictory, nor even in conflict, I can take you through some exercises that will help.

    If you disagree please provide a link that proves that
    deciders compute mappings from non-input non-strings.

    If you don't disagree then you know that embedded_H does not compute
    the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does >> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).

    (1) embedded_H is not a decider. It does not "compute the mapping from
    input finite strings to accept or reject states" because it has no
    accept state. You will, eventually, have to talk about H because that's where your big mistake is, and the only TM around that have accept and
    reject states.


    It is OK that you force me to use much more accurate language because
    this improves my professionalism. I count this as valid mentoring and appreciate your effort.

    It is certainly technically correct to say that embedded_H is not a
    decider because it lacks a final accept state. The key point that I make
    is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be correct.

    The Linz claim to have proven that embedded_H cannot possibly determine
    the correct halt status of its input is refuted.

    (2) Which strings a decider accepts and which it rejects is often
    determined by what the strings encode. H must accept those strings of
    the form <M> I such that TM M accepts input I. I.e. is accepts those
    strings that encode halting computations and rejects all others.

    (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
    is right only about that one impossible case), you must show a TM that
    does either this:

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,

    or this:

    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.

    (4) You don't have such a TM. You have nothing.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    is correct as I have proven many many times.

    You (and Linz) continue to be under the mistaken notion that a halt
    decider must determine the halt status of the computation that contains
    itself. This mistake would require a decider to base its accept or
    reject decision on a non-string, non-input.


    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Tue Mar 8 22:20:51 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/8/2022 7:14 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    It is never the case that any decider reports on the behavior of the >>>>>> computation that contains itself. Deciders are not capable of
    reporting on the behavior of Turing machines they can only accept or >>>>>> reject finite string inputs.

    I keep addressing this. Again: you are wrong, Deciders /are/ capable of >>>>> reporting on the behavior of Turing machines.

    Deciders only compute the mapping from input finite strings to accept
    or reject states.

    Of course. No one has ever disputed this obvious fact. (You only
    discovered it recently since you used to reject any talk on string
    encoding as an "extraneous detail", but now this "extraneous detail"
    gets top billing.)

    I will repeat my offer: if you would like to learn how "deciders compute >>> only a function from input strings to accept/reject states" and
    "deciders /are/ capable of reporting on the behavior of Turing machines" >>> are not contradictory, nor even in conflict, I can take you through some >>> exercises that will help.

    So you now know that everyone accepts that "deciders compute only a
    function from input strings to accept/reject states" and you also also
    now know that "deciders /are/ capable of reporting on the behavior of
    Turing machines".

    You should acknowledge when you're agreed that you have been wrong about something.


    I am not wrong. Deciders never report on the actual behavior of actual
    Turing machines. The closest that they get to this is is reporting on
    the behavior that a finite string Turing machine description specifies.

    If you disagree please provide a link that proves that
    deciders compute mappings from non-input non-strings.

    If you don't disagree then you know that embedded_H does not compute
    the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
    compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
    (1) embedded_H is not a decider. It does not "compute the mapping from
    input finite strings to accept or reject states" because it has no
    accept state. You will, eventually, have to talk about H because that's >>> where your big mistake is, and the only TM around that have accept and
    reject states.

    It is OK that you force me to use much more accurate language because
    this improves my professionalism.

    You show no professionalism.


    I am not quite yet even in the ballpark of the degree of academic professionalism required for publication in premier computer science
    journals.

    Any PhD professor of computer science that is an expert in the theory of computation on the halting problem that fully understands my work could translate my words into academic quality in a few days.

    I count this as valid mentoring and appreciate your effort.

    No you don't.


    It is inaccurate of me to not mention that some aspects of your
    critiques do have a beneficial influence on my writing style. I am
    trying to be a little more disciplined in my choice of terms.

    This whole [ more clarity ] sequence of posts was based on translating
    some of my key ideas into generic terms that are not overloaded with incongruous term-of-the-art meanings.

    It is certainly technically correct to say that embedded_H is not a
    decider because it lacks a final accept state. The key point that I
    make is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be
    correct.

    No.

    The Linz claim to have proven that embedded_H cannot possibly
    determine the correct halt status of its input is refuted.

    Linz makes no such claim.


    Do I have to quote his verbatim words all over again?

    <Linz>
    Now Ĥ is a Turing machine, so that it will have some description in
    Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ can also be used as input string. We can therefore legitimately ask what
    would happen if Ĥ is applied to ⟨Ĥ⟩.

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

    if Ĥ applied to ⟨Ĥ⟩ halts, and

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

    if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The contradiction tells us that our assumption of the existence of H, and
    hence the assumption of the decidability of the halting problem, must be
    false.

    </Linz>


    (2) Which strings a decider accepts and which it rejects is often
    determined by what the strings encode. H must accept those strings of
    the form <M> I such that TM M accepts input I. I.e. is accepts those
    strings that encode halting computations and rejects all others.

    (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
    is right only about that one impossible case), you must show a TM that
    does either this:
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    or this:
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
    (4) You don't have such a TM. You have nothing.

    I note that, again, you don't dispute that you have not such H.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    is correct as I have proven many many times.

    No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
    "correct" nor "incorrect". It is simply a statement about what a TM
    does when presented with some input. There has to be an associated
    condition by which the correctness can be assessed, and you steadfastly remove the conditions that Linz so clearly gives you:


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its final state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.

    For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
    occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.

    The whole world knows why you keep omitting the condition and, instead,
    claim that transitioning to Ĥ.qn "correct" with no reference to the
    actual condition for correctness. When pushed, you replace the actual condition with your "it had to be aborted, honest, guv" waffle in place
    of the proper condition derived from what Linz asserts about H to start
    with.

    It's all so tediously obvious. You won't be able to fool anyone with
    it.

    You (and Linz) continue to be under the mistaken notion that a halt
    decider must determine the halt status of the computation that
    contains itself.

    A halt decider, H, must be correct about every input -- even those
    strings that include something very like an encoding of H (as is the
    case for Ĥ).


    You were much sloppier in your first comment that I reponded to. Halt
    deciders do not compute the halt status of non-finite string non-inputs.

    It almost sounds like are preparing to give up on the ruse you've been
    trying to pull for the last few years, and that you are going to go back
    to the "it's an invalid question nonsense" from many years ago.

    This mistake would require a decider to base its accept or reject
    decision on a non-string, non-input.

    A decider must accept or reject every string and which one of those is
    the case is determined by the input string and nothing else. Neither I,
    nor Linz, nor anyone else, has suggested otherwise.

    Both you and Linz incorrectly believe that embedded_H must report on the non-input non-finite string of Ĥ ⟨Ĥ⟩.


    --
    Copyright 2021 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 All on Wed Mar 9 07:03:49 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/8/2022 11:32 PM, André G. Isaak wrote:
    On 2022-03-08 21:20, olcott wrote:
    On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

    No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
    "correct" nor "incorrect".  It is simply a statement about what a TM
    does when presented with some input.  There has to be an associated
    condition by which the correctness can be assessed, and you steadfastly
    remove the conditions that Linz so clearly gives you:


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
    state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
    final state.

    The above doesn't jive with the nonsense you keep asserting elsewhere.
    You keep claiming that TMs can only deal with the finite strings which
    are their inputs.


    From the above:
    ⟨Ĥ⟩ is the common convention for a finite string Turing machine description.

    Ĥ is the convention for Turing machine Ĥ.

    ⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.

    embedded_H is the convention for referring to the copy of Linz H
    embedded at Ĥ.qx.

    But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
    string nor an input to embedded_H. So why do you think that non-input non-finite string should be a valid basis for a decision criterion
    whereas Ĥ applied to ⟨Ĥ⟩ should not be?


    It it always that case that every decider computes the mapping from its
    finite string input to accept or reject state.

    In the case of a simulating halt decider this mapping is computed on the
    basis of simulating the finite string and examining the simulated
    behavior for any infinite behavior patterns.

       Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.

    For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
    occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.

    The whole world knows why you keep omitting the condition and, instead,
    claim that transitioning to Ĥ.qn "correct" with no reference to the
    actual condition for correctness.  When pushed, you replace the actual
    condition with your "it had to be aborted, honest, guv" waffle in place
    of the proper condition derived from what Linz asserts about H to start
    with.

    It's all so tediously obvious.  You won't be able to fool anyone with
    it.

    You (and Linz) continue to be under the mistaken notion that a halt
    decider must determine the halt status of the computation that
    contains itself.

    A halt decider, H, must be correct about every input -- even those
    strings that include something very like an encoding of H (as is the
    case for Ĥ).


    You were much sloppier in your first comment that I reponded to. Halt
    deciders do not compute the halt status of non-finite string non-inputs.

    It almost sounds like are preparing to give up on the ruse you've been
    trying to pull for the last few years, and that you are going to go back >>> to the "it's an invalid question nonsense" from many years ago.

    This mistake would require a decider to base its accept or reject
    decision on a non-string, non-input.

    A decider must accept or reject every string and which one of those is
    the case is determined by the input string and nothing else.  Neither I, >>> nor Linz, nor anyone else, has suggested otherwise.

    Both you and Linz incorrectly believe that embedded_H must report on
    the non-input non-finite string of Ĥ ⟨Ĥ⟩.

    It's not just Ben and Linz, but every single author who has ever written about this particular proof. That's because it *isn't* a mistake.


    As it turns out to actually be even an actual universal consensus does
    not guarantee truth. Prior to Pythagoras there was a universal consensus
    that the Earth was flat.

    Don't you think that it's a bit telling that everyone in the universe
    who actually *understands* how Turing Machine agrees with Linz, whereas
    you, who have consistently demonstrated that you've never once actually designed or worked with actual Turing Machines, are the only one who
    thinks otherwise?


    Especially not when every rebuttal to my work was like yours and
    entirely anchored in a misunderstanding of what I am even saying.

    Maybe you start by learning the basics and leave talking about Turing Machines to people who have actually dealt with Turing Machines.

    André


    I am actually starting with the establishing the fundamental
    philosophical underpinnings of the notion of truth itself.

    The majority of philosophers agree that this cannot be done because
    Willard Van Orman Quine has convinced them that they cannot really know
    that all bachelors are unmarried.

    https://www.theologie.uzh.ch/dam/jcr:ffffffff-fbd6-1538-0000-000070cf64bc/Quine51.pdf

    --
    Copyright 2021 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 Mikko on Wed Mar 9 08:15:43 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/9/2022 7:50 AM, Mikko wrote:
    On 2022-03-08 13:06:16 +0000, olcott said:

    On 3/8/2022 5:36 AM, Ben Bacarisse wrote:
    Mikko <mikko.levanto@iki.fi> writes:

    On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:

    Mikko <mikko.levanto@iki.fi> writes:

    On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:

    The words used don't alter the facts -- that there is no TM
    satisfying Linz's 12.1 can be, loosely, stated as "there is no
    decider for the strings that represent halting computations".
    Words can be (and often are) used to hide facts.
    But not, as far as I can see, in this case.  The meaning of
    "decider" --
    a TM whose language is decidable -- is not causing any confusion.  OK, >>>>> PO lies about what other people say and/or know about "deciders", but >>>>> the fault there is in the lying, not in the words used.

    In this case the probable intent was to argue about an irrelevance in
    order to draw attention from the fact that the presented soulution does >>>> not satisfy the definitiopn (21.1) of a solution to the halting
    problem.

    That's possible.


    I conclusively proved that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    never reaches its final state of ⟨Ĥ⟩.qn thus proving that embedded_H
    would be correct to reject its input. This refutes the Linz proof that
    concludes this is impossible.

    Linz did not present any proof with that conclusion, so you only refuted
    (or
    at least tried to refute) a straw man.


    I keep proving that Linz did prove this yet now-a-days with "alternative
    facts" it seems that many people actually believe that they can make up
    their own "facts".

    what would happen if Ĥ is applied to ⟨Ĥ⟩.
    what would happen if Ĥ is applied to ⟨Ĥ⟩.
    what would happen if Ĥ is applied to ⟨Ĥ⟩.

    <Linz:1990:320>
    Now Ĥ is a Turing machine, so that it will have some description in
    Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ can also be used as input string. We can therefore legitimately ask what
    would happen if Ĥ is applied to ⟨Ĥ⟩.

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

    if Ĥ applied to ⟨Ĥ⟩ halts, and

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

    if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The contradiction tells us that our assumption of the existence of H, and
    hence the assumption of the decidability of the halting problem, must be
    false.
    </Linz:1990:320>

    https://www.liarparadox.org/Linz_Proof.pdf

    Linz is confused into believing that the copy of H embedded at Ĥ.qx must
    base its halt status decision on the non-finite string non-input of: Ĥ
    applied to ⟨Ĥ⟩.

    It is the case that deciders only compute the mapping from their input
    finite strings to an accept or reject state. This means that embedded_H computes its mapping from ⟨Ĥ⟩ ⟨Ĥ⟩.

    Instead, Linz concluded that no Turing machine is a solution to the halting problem as defined in definition 12.1. That conclusion you have not
    refuted.

    Mikko



    --
    Copyright 2021 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 Mikko on Wed Mar 9 13:17:10 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/9/2022 12:25 PM, Mikko wrote:
    On 2022-03-09 14:15:43 +0000, olcott said:

    Linz is confused into believing that the copy of H embedded at Ĥ.qx
    must base its halt status decision on the non-finite string non-input
    of: Ĥ applied to ⟨Ĥ⟩.

    What does that "must" mean?

    Linz simply infers what Ĥ does from the way it is constructed, to the
    extent it can be inferred. There is no confusion, the inference is correct.

    Mikko


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its final state.

    The copy of Linz H at Ĥ.qx is referred to as embedded_H

    <Linz:1990:320>
    Now Ĥ is a Turing machine, so that it will have some description in
    Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ can also be used as input string. We can therefore legitimately ask what
    would happen if Ĥ is applied to ⟨Ĥ⟩.

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

    if Ĥ applied to ⟨Ĥ⟩ halts, and

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

    if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The contradiction tells us that our assumption of the existence of H, and
    hence the assumption of the decidability of the halting problem, must be
    false.
    </Linz:1990:320>

    https://www.liarparadox.org/Linz_Proof.pdf

    As quoted above Linz believes that the halt status decision of
    embedded_H is based on the behavior of a non-input, non-finite string: Ĥ applied to ⟨Ĥ⟩ rather than the actual behavior of the actual finite
    string input: ⟨Ĥ⟩ ⟨Ĥ⟩ shown below:

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...



    --
    Copyright 2021 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 All on Thu Mar 10 09:06:48 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/9/2022 8:50 PM, André G. Isaak wrote:
    On 2022-03-09 06:03, olcott wrote:
    On 3/8/2022 11:32 PM, André G. Isaak wrote:
    On 2022-03-08 21:20, olcott wrote:
    On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

    No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
    "correct" nor "incorrect".  It is simply a statement about what a TM >>>>> does when presented with some input.  There has to be an associated >>>>> condition by which the correctness can be assessed, and you
    steadfastly
    remove the conditions that Linz so clearly gives you:


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its >>>> final state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach
    its final state.

    The above doesn't jive with the nonsense you keep asserting
    elsewhere. You keep claiming that TMs can only deal with the finite
    strings which are their inputs.


     From the above:
    ⟨Ĥ⟩ is the common convention for a finite string Turing machine
    description.

    Ĥ is the convention for Turing machine Ĥ.

    ⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.

    embedded_H is the convention for referring to the copy of Linz H
    embedded at Ĥ.qx.

    I'm not sure why you're responding with all the above. I've read Linz
    and I've read your previous posts so I already know how you are using
    these terms.

    But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
    string nor an input to embedded_H. So why do you think that non-input
    non-finite string should be a valid basis for a decision criterion
    whereas Ĥ applied to ⟨Ĥ⟩ should not be?


    It it always that case that every decider computes the mapping from
    its finite string input to accept or reject state.

    In the case of a simulating halt decider this mapping is computed on
    the basis of simulating the finite string and examining the simulated
    behavior for any infinite behavior patterns.

    But the point is that in your criteria above you keep talking about the
    "pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H"

    Your embedded_H is *not* a pure simulator; it is a modified copy of what
    you claim to be a simulating halt decider but with its accepting state replaced by an infinite loop.

    So you are asking it to base its decision on the behaviour of some hypothetical "pure simulator" which is *not* a string nor the input to embedded_H.

    embedded_H contains all of the functionality of a UTM as well as
    additional halt deciding functionality. The halt deciding functionality
    bases its halt status decision on matching infinite behavior patterns,
    or failing to match any of these patterns.

    Why is that allowed but it is not allowed to base a decision
    on the behaviour of Ĥ (which while not a string nor an actual input is
    at least a TM which embedded_H has a complete description of) applied to ⟨Ĥ⟩?


    All deciders map finite string inputs to an accept or reject state.
    ⟨Ĥ⟩ ⟨Ĥ⟩ are finite string inputs to embedded_H. Ĥ is neither a finite
    string nor an input to to embedded_H.

       Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.

    For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
    occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.

    The whole world knows why you keep omitting the condition and,
    instead,
    claim that transitioning to Ĥ.qn "correct" with no reference to the >>>>> actual condition for correctness.  When pushed, you replace the actual >>>>> condition with your "it had to be aborted, honest, guv" waffle in
    place
    of the proper condition derived from what Linz asserts about H to
    start
    with.

    It's all so tediously obvious.  You won't be able to fool anyone with >>>>> it.

    You (and Linz) continue to be under the mistaken notion that a halt >>>>>> decider must determine the halt status of the computation that
    contains itself.

    A halt decider, H, must be correct about every input -- even those
    strings that include something very like an encoding of H (as is the >>>>> case for Ĥ).


    You were much sloppier in your first comment that I reponded to.
    Halt deciders do not compute the halt status of non-finite string
    non-inputs.

    It almost sounds like are preparing to give up on the ruse you've been >>>>> trying to pull for the last few years, and that you are going to go
    back
    to the "it's an invalid question nonsense" from many years ago.

    This mistake would require a decider to base its accept or reject
    decision on a non-string, non-input.

    A decider must accept or reject every string and which one of those is >>>>> the case is determined by the input string and nothing else.
    Neither I,
    nor Linz, nor anyone else, has suggested otherwise.

    Both you and Linz incorrectly believe that embedded_H must report on
    the non-input non-finite string of Ĥ ⟨Ĥ⟩.

    It's not just Ben and Linz, but every single author who has ever
    written about this particular proof. That's because it *isn't* a
    mistake.


    As it turns out to actually be even an actual universal consensus does
    not guarantee truth. Prior to Pythagoras there was a universal
    consensus that the Earth was flat.

    <pedantry> Your facts here are incorrect. There is no evidence to
    suggest that there was a universal consensus that the earth was flat
    prior to Pythagoras. </pedantry>

    Don't you think that it's a bit telling that everyone in the universe
    who actually *understands* how Turing Machine agrees with Linz,
    whereas you, who have consistently demonstrated that you've never
    once actually designed or worked with actual Turing Machines, are the
    only one who thinks otherwise?


    Especially not when every rebuttal to my work was like yours and
    entirely anchored in a misunderstanding of what I am even saying.

    Maybe you start by learning the basics and leave talking about Turing
    Machines to people who have actually dealt with Turing Machines.

    André


    I am actually starting with the establishing the fundamental
    philosophical underpinnings of the notion of truth itself.

    But the issue here has nothing to do with "truth" but with how Turing Machines work.

    If you were to actually look at some examples of real Turing Machines
    maybe you would come to understand this. When we try to construct a TM
    to compute some function one of the first steps involved is to figure
    out how to encode elements of the domain of that function as strings
    which can actually be passed to a TM. But the TM is still expected to
    process those strings in a way which actually conforms to the function
    being computed.

    Consider a TM which decides whether a given integer x is even or not.
    There is no way in which we can pass an actual integer to a TM, since an integer is not a string. But we can easily come up with a way of
    encoding the integer x as a string ⟨x⟩ which *can* be passed to an integer.

    Whether the above TM accepts or rejects ⟨x⟩ *must* depend on whether x
    is even or odd. Otherwise it isn't computing the function it purports to compute. And if you claim it is only responsible for determining the
    mapping from the string ⟨x⟩ which is its input rather than the actual integer x, which is not its input, then any reasonable person is going
    to respond with a look of utter confusion. What does it even *mean* to
    talk about the evenness of ⟨x⟩ if it is not related to the evenness of the actual integer x? Strings aren't 'even' anymore than they are
    'halting'.


    embedded_H is only responsible for computing the mapping from its inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to an accept or reject state based on the behavior that ⟨Ĥ⟩ ⟨Ĥ⟩
    specifies. A pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is the ultimate measure of the behavior that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies.

    The majority of philosophers agree that this cannot be done because
    Willard Van Orman Quine has convinced them that they cannot really
    know that all bachelors are unmarried.

    Yes, you've already demonstrated that you are unable to appreciate the
    nuance of Quine's article and have instead settled on this ridiculous interpretation. Nobody cares.

    André

    Rudolf Carnap wrote a meaning postulate in his debate with Quine that
    specifies ∀x (bachelor(x) → ¬married(x)) and Quine still did not get it. To the best of my knowledge this was the first step towards the Richard Montague grammar of natural language semantics. https://liarparadox.org/Meaning_Postulates_Rudolf_Carnap_1952.pdf


    --
    Copyright 2021 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 Mikko on Thu Mar 10 08:43:34 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/10/2022 3:18 AM, Mikko wrote:
    On 2022-03-09 19:17:10 +0000, olcott said:

    <Linz:1990:320>
         Now Ĥ is a Turing machine, so that it will have some description >> in Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ
    can also be used as input string. We can therefore legitimately ask
    what would happen if Ĥ is applied to ⟨Ĥ⟩.

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

    if Ĥ applied to ⟨Ĥ⟩ halts, and

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

    if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
    contradiction tells us that our assumption of the existence of H, and
    hence the assumption of the decidability of the halting problem, must
    be false.
    </Linz:1990:320>

    https://www.liarparadox.org/Linz_Proof.pdf

    As quoted above Linz believes that the halt status decision of
    embedded_H is based on the behavior of a non-input, non-finite string:
    Ĥ applied to ⟨Ĥ⟩ rather than the actual behavior of the actual finite >> string input:
     ...

    Your quote does not say so. Ĥ goes to Ĥ.qy if H goes to H.qy and to Ĥ.qn if
    H goes to H.qn because that is how Ĥ is constructed. Your "based on" does not come from the quote, as is easily observed.

    Mikko


    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    It is "easily observed" that the simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ would never reach its final state of ⟨Ĥ⟩.qn in any finite number of steps. This is
    the definition of non halting behavior.

    Because embedded_H only computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ and
    not from the behavior of the computation that it is contained within: Ĥ ⟨Ĥ⟩ embedded_H would be correct to reject its input.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Mar 11 10:05:58 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

    So you now know that everyone accepts that "deciders compute only a
    function from input strings to accept/reject states"

    This is good.

    and you also also
    now know that "deciders /are/ capable of reporting on the behavior of
    Turing machines".

    This contradicts the prior sentence:
    (a) A decider only takes finite string inputs. // prior sentence
    (b) A decider takes Turing machine (thus non-finite string) inputs. //
    current sentence


    You should acknowledge when you're agreed that you have been wrong about >>> something.

    I am not wrong.

    I never really thought did agree that were wrong. I was just pointing
    out your habit of glossing over so many points made to you. It means to
    no agreement can ever be reached because you are always moving on by
    making new mistakes. I will continue to assume that if you don't say
    "no" you agree with what you are quoting.


    Your own words contradicted themselves so it is you mistake and not mine.

    Deciders never report on the actual behavior of actual
    Turing machines. The closest that they get to this is is reporting on
    the behavior that a finite string Turing machine description
    specifies.

    Pure sophistry. It's not "close" it's exact. To say that the string
    <M>I encodes a halting computation is to report on the behaviour of the
    TM M with input I.


    Deciders take finite string inputs that specify Turing machine
    computations.

    Deciders do not take Turing machine inputs.

    You can insist, if you want, that we (and that includes you as well)
    must always say things like

    Ĥ.q0 ⟨Ĥ⟩⊢* Ĥ.qn
    if ⟨Ĥ⟩ is the encoding of a TM, Ĥ that does not halt when run with
    the input string ⟨Ĥ⟩.

    but it won't change the fact that you are wrong about Ĥ.


    Both you and Linz get confused because both you and Linz leave out key
    details.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its final state.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    Thus proving that the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H never reaches its own final state ⟨Ĥ⟩.qn in any finite number of steps of pure simulation.

    It is OK that you force me to use much more accurate language because
    this improves my professionalism.

    You show no professionalism.

    I am not quite yet even in the ballpark of the degree of academic
    professionalism required for publication in premier computer science
    journals.

    You are not out of the grade-school ballpark yet -- calling clever
    people nitwits, and repeating banal lines in ALL CAPS twenty times like
    a petulant toddler.


    It is required that I repeat some points many times to get you to
    finally quit simply ignoring these crucially important points. I usually
    wait for five back and forth exchanges before I realize that you intend
    to perpetually ignore a crucial point.

    If you would be more respectful and never ignore any crucially important
    point I would never need to do this.

    The biggest step towards an academic degree of professionalism is my
    statement that all deciders compute the mapping from their finite string
    inputs to an accept of reject state.

    This is a big step because I have finally specified the notion of a
    computable function precisely correctly and succinctly.

    Any PhD professor of computer science that is an expert in the theory
    of computation on the halting problem that fully understands my work
    could translate my words into academic quality in a few days.

    No they could not. Academic work must be, first and foremost, correct,
    and you are not. Any qualified person who understand what you are
    saying can only translate it as "don't keep working on this, go help out
    at the dog shelter".


    So far the maximum logical basis that anyone has presented in their
    attempt to form a rebuttal is "we really really don't believe you".

    By the way, why are cranks so obsessed with PhDs? It was not so long
    ago (when I was a CS professor in the US sense of the word) that all the

    Doubtful. Most are associate professors or assistant professors and all
    of these have a PhD. There is only one Distinguished Professor that I
    know of: Saul Kripke, (originally from mu home town) that only has a
    bachelors degree.

    "PhD professors" of CS had PhDs in physics or engineering because the
    subject was quite new. Anyway, a PhD is always about a very narrowly
    focused picece of work. Do you think someone with a PhD in database
    storage for traditional Scottish Country Dances (an actual example of
    someone I worked with) will even know what you are talking about?


    You simply ignored the rest of the details of qualifications that I
    specified:

    professor of computer science that is an expert in the theory
    of computation on the halting problem that fully understands my work

    The Linz claim to have proven that embedded_H cannot possibly
    determine the correct halt status of its input is refuted.

    Linz makes no such claim.

    Do I have to quote his verbatim words all over again?

    No, because he makes no such claim. Repeating some text where he makes
    no such claim is just pointless.

    <Linz>
    Now Ĥ is a Turing machine, so that it will have some description
    in Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ
    can also be used as input string. We can therefore legitimately ask
    what would happen if Ĥ is applied to ⟨Ĥ⟩.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>
    if Ĥ applied to ⟨Ĥ⟩ halts, and

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

    I don't know weather it's deliberate, but this is not a quote form
    Linz. Linz says (using your notation)


    The Linz notation glosses over key details.

    "We can therefore legitimately ask what would happen if Ĥ is applied
    to ⟨Ĥ⟩. From the above, identifying M with Ĥ, we get

    Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞

    if Ĥ applied to ⟨Ĥ⟩ halts, and

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn

    if Ĥ applied to ⟨Ĥ⟩ does not halt."

    So, no, he is saying nothing about the embedded H here.

    He is referring to Ĥ and simply deleting some of its key state
    transitions as if they don't exist. He is not being dishonest he is only
    trying to be concise. The effect, however is self deception.

    Here is his original notation before he simply deleted part of it
    q0 Wm ⊢* Ĥq0 Wm Wm ⊢* ∞
    q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2

    Here is my correction, simplification and clarification of his notation
    in the case where Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    https://www.liarparadox.org/Linz_Proof.pdf

    He does not
    even refer to it. You dishonestly put it back in the hope of suggesting
    that maybe Linz was saying something about it. That's a million miles
    from academic professionalism.

    Linz simply writes out, in sequence, what we know about H' and the Ĥ
    from the definition of what H does. The result is a contradictory:


    You and Linz both remain confused into thinking that a decider is
    supposed to report on its own actual behavior rather than the behavior
    that its finite string input specifies.

    This is clearly nonsense. The
    contradiction tells us that our assumption of the existence of H, and
    hence the assumption of the decidability of the halting problem, must
    be false.
    </Linz>

    (3) Even if all you want is a TM the "refutes the proof" (i.e. one that >>>>> is right only about that one impossible case), you must show a TM that >>>>> does either this:
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
    or this:
    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
    (4) You don't have such a TM. You have nothing.

    I note that, again, you don't dispute that you have not such H.

    And I note it again. You don't, do you?


    The claim that I unequivocally proved is that if embedded_H did reject
    its input it would be correct. Linz claims that whether embedded_H
    accepts or rejects its input it is incorrect.

    He makes this mistake because he truncated key details of the
    specification of Ĥ in his analysis of the behavior of Ĥ. This caused him
    to conflate the behavior of the computation that contains embedded_H
    with the behavior specified by the input to embedded_H.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    is correct as I have proven many many times.

    No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
    "correct" nor "incorrect". It is simply a statement about what a TM
    does when presented with some input. There has to be an associated
    condition by which the correctness can be assessed, and you steadfastly
    remove the conditions that Linz so clearly gives you:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
    final state.

    Yes, yes, we know about your other not-quite-the halting problem.
    You've been flip-flopping like this for months: refer to Linz, then flip
    the condition to your own silly one in the hope that no one notices this
    is not Linz's Ĥ any more.


    It is exactly Linz with the mistake of Linz removed.

    You can't seriously think that's going to work any better than the old
    "yes it halts, but only because ..." or the even more ludicrous "it's correct because of what would happen if line 15 were commented out".
    You've been trying to pull some variation of this "it's correct because
    of what would happen if it were not quote what it is" ruse for ages.

    No one is buying it. Please find something more rewarding to do.


    It is the case that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ never halts no matter what embedded_H would or would not do:

    (a) embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ never aborts its simulation thus the simulated input never reaches its final state of ⟨Ĥ⟩.qn.

    (b) embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation thus the simulated input is
    aborted before reaching its final state.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    embedded_H either simulates its input or aborts this simulation.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Sat Mar 12 15:14:30 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

    So you now know that everyone accepts that "deciders compute only a
    function from input strings to accept/reject states"

    This is good.

    and you also also
    now know that "deciders /are/ capable of reporting on the behavior of >>>>> Turing machines".

    This contradicts the prior sentence:
    (a) A decider only takes finite string inputs. // prior sentence
    (b) A decider takes Turing machine (thus non-finite string) inputs. //
    current sentence

    I can't help with your poor comprehension of English.


    A decider cannot take a Turing machine as input and you know it.
    It can only take a finite string that specifies a Turing machine.

    ... To say that the string <M>I encodes a halting computation is to
    report on the behaviour of the TM M with input I.

    Deciders take finite string inputs that specify Turing machine computations. >>
    Deciders do not take Turing machine inputs.

    I have offered to help with this point of comprehension but you have not taken me up on it.

    I am being 100% literal and you are being figurative.

    Maybe you have decided that this misrepresentation
    is your last best hope of distracting readers from the big mistake --
    that your H rejects strings that encode halting computations.


    When this point is fully understood it will be known that I am correct.

    You can insist, if you want, that we (and that includes you as well)
    must always say things like
    Ĥ.q0 ⟨Ĥ⟩⊢* Ĥ.qn
    if ⟨Ĥ⟩ is the encoding of a TM, Ĥ that does not halt when run with
    the input string ⟨Ĥ⟩.
    but it won't change the fact that you are wrong about Ĥ.

    Both you and Linz get confused because both you and Linz leave out key details.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
    final state.

    This is not Linz's Ĥ.

    The encoding is corrected, simplified and replaces variables with
    literal strings. Only the criterion measure is different.

    You have made up these conditions so that your H
    can reject strings the encode halting computations, but they can't be
    derived from the initial conditions Linz places on H. Your Ĥ is
    irrelevant to the proof you are obsessed with.


    It is the case that Linz said Ĥ applied to its own Turing machine
    description would derive contradiction in both of its two possible
    sequences of configurations. https://www.liarparadox.org/Linz_Proof.pdf

    YOU KEEP DODGING THIS POINT
    YOU KEEP DODGING THIS POINT
    YOU KEEP DODGING THIS POINT
    YOU KEEP DODGING THIS POINT
    YOU KEEP DODGING THIS POINT

    It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the copy
    of H embedded within Ĥ would never reach the final state of this input ⟨Ĥ⟩.qn.

    This proves that a transition to Ĥ.qn by the copy of H embedded within
    Ĥ would be correct and would not derive the contradiction that Linz
    claims, thus refuting the Linz proof.

    --
    Copyright 2021 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 All on Sat Mar 12 17:25:18 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/12/2022 3:33 PM, André G. Isaak wrote:
    On 2022-03-12 14:14, olcott wrote:
    On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

    So you now know that everyone accepts that "deciders compute only a >>>>>>> function from input strings to accept/reject states"

    This is good.

    and you also also
    now know that "deciders /are/ capable of reporting on the
    behavior of
    Turing machines".

    This contradicts the prior sentence:
    (a) A decider only takes finite string inputs. // prior sentence
    (b) A decider takes Turing machine (thus non-finite string) inputs. // >>>> current sentence

    I can't help with your poor comprehension of English.


    A decider cannot take a Turing machine as input and you know it.

    Nowhere does he deny this.

    It can only take a finite string that specifies a Turing machine.

    Right. A finite string THAT SPECIFIES A TURING MACHINE.

    IOW, it is given a string which provides all of the information
    necessary to identify some unique Turing Machine. So while a TM cannot
    take a Turing Machine as an input, it can still answer questions about
    Turing Machines.


    It is not actually answering the question about a Turing machine.
    It is answering the question about the Turing machine specified by the
    finite string, this distinction is crucial, and even Linz missed it.

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

    Everyone here (and Linz) believes that the copy of H embedded at Ĥ.qx is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. This is off by exactly one level of indirection.

    No decider is ever supposed to report on the behavior of the computation
    that contains its actual self. Deciders only report on the behavior
    specified by Turing machine descriptions.

    That's a fairly fundamental concept in computational theory which you
    seem determined to not understand.

    Turing Machines only deal with strings. This means that a function can
    only be computed if (as a minimal requirement) the elements of that
    domain can be ENCODED as strings. If you can encoded elements of some
    domain as strings, then it might be possible for a TM to compute that function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES STRINGS.

    Integers are not strings, but many functions from integers to integers
    are computable by virtue of the fact that it is trivially easy to devise
    ways of encoding integers as strings.

    Functions from reals to reals, on the other hand, are not going to be computable precisely because the overwhelming majority of real numbers
    cannot be encoded as finite strings. A function like y = √x is not computable, but one can compute some function that is "close" to this
    but that limits the input/output to some arbitary degree of precision.

    The set of Turing Machines is provably DENUMERABLE. That means that one
    can encode TMs as finite strings. Which in turn means that a TM *can*
    answer questions about Turing Machines. They just have to be encoded as finite strings before being given to a Turing Machine.

    Strings which encode Turing Machines and inputs don't halt anymore than strings which encode integers have sums.

    The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never reaches
    its final state of ⟨Ĥ⟩.qn in any finite number of correctly simulated steps by the copy of H embedded at Ĥ.qx.

    This fact logically entails that a state transition to Ĥ.qn by the copy
    of H embedded at Ĥ.qx would be correct and not form any contradiction as
    Linz claims at the end of his proof.
    https://www.liarparadox.org/Linz_Proof.pdf

    Turing Machines applied to
    strings can halt and integers can have sums. But to talk about the
    halting status of the STRING ⟨Ĥ⟩ ⟨Ĥ⟩ is meaningless gibberish.

    André



    --
    Copyright 2021 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 All on Sat Mar 12 18:17:01 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/12/2022 5:57 PM, André G. Isaak wrote:
    On 2022-03-12 16:25, olcott wrote:
    On 3/12/2022 3:33 PM, André G. Isaak wrote:
    On 2022-03-12 14:14, olcott wrote:
    On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

    So you now know that everyone accepts that "deciders compute >>>>>>>>> only a
    function from input strings to accept/reject states"

    This is good.

    and you also also
    now know that "deciders /are/ capable of reporting on the
    behavior of
    Turing machines".

    This contradicts the prior sentence:
    (a) A decider only takes finite string inputs. // prior sentence
    (b) A decider takes Turing machine (thus non-finite string)
    inputs. //
    current sentence

    I can't help with your poor comprehension of English.


    A decider cannot take a Turing machine as input and you know it.

    Nowhere does he deny this.

    It can only take a finite string that specifies a Turing machine.

    Right. A finite string THAT SPECIFIES A TURING MACHINE.

    IOW, it is given a string which provides all of the information
    necessary to identify some unique Turing Machine. So while a TM
    cannot take a Turing Machine as an input, it can still answer
    questions about Turing Machines.


    It is not actually answering the question about a Turing machine.
    It is answering the question about the Turing machine specified by the
    finite string, this distinction is crucial, and even Linz missed it.

    The Turing Machine specified by the finite string *is* a Turing Machine,
    so yes it is answering the question about a Turing Machine.

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

    Everyone here (and Linz) believes that the copy of H embedded at Ĥ.qx
    is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. This is off >> by exactly one level of indirection.

    That's exactly what the copy of H embedded at Ĥ.qx is supposed to report
    on by the very definition of the problem.

    A halt decider must, *by definition*, be able to determine the halting
    status of *any* arbitrary computation, so if you want to claim that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a computation different from Ĥ applied to ⟨Ĥ⟩, then you'd
    better be able to show how that latter computation is to be encoded as a finite string.

    So what string, according to you, encodes the computation Ĥ applied to ⟨Ĥ⟩? If these two "different" computations don't have separate encodings as strings then they are not, in fact, different computations at all.


    No decider is ever supposed to report on the behavior of the
    computation that contains its actual self. Deciders only report on the
    behavior specified by Turing machine descriptions.

    No, it is supposed to report on the halting status of the computation represented by its input. But nothing in the definition of 'halt
    decider' precludes it from being given a description of a computation
    which contains its actual self. If it can't answer about that question,
    then it isn't meeting the definition of a halt decider which must be
    able to answer about *any* computation. And in the Linz proof this is precisely what the input specifies, your nonsense about the input being
    a string rather than an actual Turing Machine notwithstanding.


    That's a fairly fundamental concept in computational theory which you
    seem determined to not understand.

    Turing Machines only deal with strings. This means that a function
    can only be computed if (as a minimal requirement) the elements of
    that domain can be ENCODED as strings. If you can encoded elements of
    some domain as strings, then it might be possible for a TM to compute
    that function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES STRINGS.

    Integers are not strings, but many functions from integers to
    integers are computable by virtue of the fact that it is trivially
    easy to devise ways of encoding integers as strings.

    Functions from reals to reals, on the other hand, are not going to be
    computable precisely because the overwhelming majority of real
    numbers cannot be encoded as finite strings. A function like y = √x
    is not computable, but one can compute some function that is "close"
    to this but that limits the input/output to some arbitary degree of
    precision.

    The set of Turing Machines is provably DENUMERABLE. That means that
    one can encode TMs as finite strings. Which in turn means that a TM
    *can* answer questions about Turing Machines. They just have to be
    encoded as finite strings before being given to a Turing Machine.

    Strings which encode Turing Machines and inputs don't halt anymore
    than strings which encode integers have sums.

    The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never >> reaches its final state of ⟨Ĥ⟩.qn in any finite number of correctly
    simulated steps by the copy of H embedded at Ĥ.qx.

    Finite string pairs don't *have* final states.

    Simulated finite string pairs ⟨Ĥ⟩ ⟨Ĥ⟩ have final states that can either
    be reached in a finite number of simulated steps or not.

    They don't have states at
    all. It doesn't matter how you try to phrase this; your claim is simply incoherent. The finite strings which are given to a halt decider do not
    have states, let alone final ones. Only the computations which they
    represent have these.

    André





    --
    Copyright 2021 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 All on Sat Mar 12 20:13:24 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/12/2022 7:03 PM, André G. Isaak wrote:
    On 2022-03-12 17:17, olcott wrote:
    On 3/12/2022 5:57 PM, André G. Isaak wrote:
    On 2022-03-12 16:25, olcott wrote:
    On 3/12/2022 3:33 PM, André G. Isaak wrote:
    On 2022-03-12 14:14, olcott wrote:
    On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

    So you now know that everyone accepts that "deciders compute >>>>>>>>>>> only a
    function from input strings to accept/reject states"

    This is good.

    and you also also
    now know that "deciders /are/ capable of reporting on the >>>>>>>>>>> behavior of
    Turing machines".

    This contradicts the prior sentence:
    (a) A decider only takes finite string inputs. // prior sentence >>>>>>>> (b) A decider takes Turing machine (thus non-finite string)
    inputs. //
    current sentence

    I can't help with your poor comprehension of English.


    A decider cannot take a Turing machine as input and you know it.

    Nowhere does he deny this.

    It can only take a finite string that specifies a Turing machine.

    Right. A finite string THAT SPECIFIES A TURING MACHINE.

    IOW, it is given a string which provides all of the information
    necessary to identify some unique Turing Machine. So while a TM
    cannot take a Turing Machine as an input, it can still answer
    questions about Turing Machines.


    It is not actually answering the question about a Turing machine.
    It is answering the question about the Turing machine specified by
    the finite string, this distinction is crucial, and even Linz missed
    it.

    The Turing Machine specified by the finite string *is* a Turing
    Machine, so yes it is answering the question about a Turing Machine.

    Can I take your silence here as an acknowledgment that what you had
    written was an error (and a very silly one at that)?

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

    Everyone here (and Linz) believes that the copy of H embedded at
    Ĥ.qx is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. This
    is off by exactly one level of indirection.

    That's exactly what the copy of H embedded at Ĥ.qx is supposed to
    report on by the very definition of the problem.

    No Comment?

    A halt decider must, *by definition*, be able to determine the
    halting status of *any* arbitrary computation, so if you want to
    claim that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a computation different from Ĥ applied to
    ⟨Ĥ⟩, then you'd better be able to show how that latter computation is >>> to be encoded as a finite string.

    So what string, according to you, encodes the computation Ĥ applied
    to ⟨Ĥ⟩? If these two "different" computations don't have separate
    encodings as strings then they are not, in fact, different
    computations at all.

    No Comment?

    I know you've been asked this question before and have consistently
    ignored it. According to a recent post of yours that constitutes justification for a repetitive all-caps temper tantrum!


    No decider is ever supposed to report on the behavior of the
    computation that contains its actual self. Deciders only report on
    the behavior specified by Turing machine descriptions.

    No, it is supposed to report on the halting status of the computation
    represented by its input. But nothing in the definition of 'halt
    decider' precludes it from being given a description of a computation
    which contains its actual self. If it can't answer about that
    question, then it isn't meeting the definition of a halt decider
    which must be able to answer about *any* computation. And in the Linz
    proof this is precisely what the input specifies, your nonsense about
    the input being a string rather than an actual Turing Machine
    notwithstanding.

    Again, is your silence a recognition that you know see your error?


    That's a fairly fundamental concept in computational theory which
    you seem determined to not understand.

    Turing Machines only deal with strings. This means that a function
    can only be computed if (as a minimal requirement) the elements of
    that domain can be ENCODED as strings. If you can encoded elements
    of some domain as strings, then it might be possible for a TM to
    compute that function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES
    STRINGS.

    Integers are not strings, but many functions from integers to
    integers are computable by virtue of the fact that it is trivially
    easy to devise ways of encoding integers as strings.

    Functions from reals to reals, on the other hand, are not going to
    be computable precisely because the overwhelming majority of real
    numbers cannot be encoded as finite strings. A function like y = √x >>>>> is not computable, but one can compute some function that is
    "close" to this but that limits the input/output to some arbitary
    degree of precision.

    The set of Turing Machines is provably DENUMERABLE. That means that
    one can encode TMs as finite strings. Which in turn means that a TM
    *can* answer questions about Turing Machines. They just have to be
    encoded as finite strings before being given to a Turing Machine.

    Strings which encode Turing Machines and inputs don't halt anymore
    than strings which encode integers have sums.

    The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never >>>> reaches its final state of ⟨Ĥ⟩.qn in any finite number of correctly >>>> simulated steps by the copy of H embedded at Ĥ.qx.

    Finite string pairs don't *have* final states.

    Simulated finite string pairs ⟨Ĥ⟩ ⟨Ĥ⟩ have final states that can >> either be reached in a finite number of simulated steps or not.


    I am ignoring all of your other points because this single point is the
    crux of the whole issue and all the other points are tangential.

    The *simulation* has states which may include final states. The string
    itself does not.

    A BASIC program that is executed in an interpreter is correctly
    construed as reaching its final state.

    10 PRINT "Hello, World!"
    20 END

    ⟨Ĥ⟩ ⟨Ĥ⟩ is executed within the simulator of the copy of H embedded within Ĥ. This embedded_H has all of the functionality of a UTM along
    with additional functionality.

    But SIMULATOR applied to ⟨Ĥ⟩ ⟨Ĥ⟩ and Ĥ applied to ⟨Ĥ⟩
    are distinct computations which thus must be encodable by distinct
    finite strings.

    So are you now attempting to claim that the finite string ⟨Ĥ⟩ ⟨Ĥ⟩ is
    supposed to encode the computation SIMULATOR applied to ⟨Ĥ⟩ ⟨Ĥ⟩?

    If so, how do we encode Ĥ applied to ⟨Ĥ⟩ which is the computation that is actually of interest to us?

    André


    It is impossible for any decider to correctly report on the behavior of
    the computation that contains itself.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Mon Mar 14 20:19:48 2022
    XPost: comp.theory

    On 3/12/2022 8:55 PM, Ben Bacarisse wrote:
    André G. Isaak <agisaak@gm.invalid> writes:

    On 3/12/2022 5:57 PM, André G. Isaak wrote:

    So what string, according to you, encodes the computation Ĥ applied
    to ⟨Ĥ⟩? If these two "different" computations don't have separate >>>> encodings as strings then they are not, in fact, different
    computations at all.

    No Comment?

    I know you've been asked this question before and have consistently
    ignored it. According to a recent post of yours that constitutes
    justification for a repetitive all-caps temper tantrum!

    I once tried to get a direct answer to this question. I asked 12 times
    in consecutive posts but never got one.

    Later, on the related question of whether ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation I got this dazzling display of equivocation:

    "When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
    computation.
    When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES NOT encode a
    halting computation."

    Bear in mind that at time, PO's machines were magic: two identical state transition functions could entail transitions to different states when presented with identical inputs. He has since backed off from some of
    these remarks, but it never exactly clear which previous claims he would
    now accept were wrong.



    None-the-less when a BASIC interpreter is running a BASIC program or a simulating halt decider with UTM functionality is simulating a Turing
    machine description in each of these two cases their input would either
    reach or fail to reach a final state.

    10 PRINT "Hello, World!"
    20 END

    10 PRINT "Hello, World!"
    20 GOTO 10
    30 END

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    The above repeating pattern shows that the correctly simulated input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively proving that this simulated input never halts. This enables embedded_H
    to abort its simulation and correctly transition to Ĥ.qn.



    --
    Copyright 2021 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 All on Mon Mar 14 20:17:12 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/12/2022 8:30 PM, André G. Isaak wrote:
    On 2022-03-12 19:13, olcott wrote:
    On 3/12/2022 7:03 PM, André G. Isaak wrote:
    On 2022-03-12 17:17, olcott wrote:
    On 3/12/2022 5:57 PM, André G. Isaak wrote:
    On 2022-03-12 16:25, olcott wrote:
    On 3/12/2022 3:33 PM, André G. Isaak wrote:
    On 2022-03-12 14:14, olcott wrote:
    On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 3/8/2022 9:41 PM, Ben Bacarisse wrote:

    So you now know that everyone accepts that "deciders >>>>>>>>>>>>> compute only a
    function from input strings to accept/reject states"

    This is good.

    and you also also
    now know that "deciders /are/ capable of reporting on the >>>>>>>>>>>>> behavior of
    Turing machines".

    This contradicts the prior sentence:
    (a) A decider only takes finite string inputs. // prior sentence >>>>>>>>>> (b) A decider takes Turing machine (thus non-finite string) >>>>>>>>>> inputs. //
    current sentence

    I can't help with your poor comprehension of English.


    A decider cannot take a Turing machine as input and you know it. >>>>>>>
    Nowhere does he deny this.

    It can only take a finite string that specifies a Turing machine. >>>>>>>
    Right. A finite string THAT SPECIFIES A TURING MACHINE.

    IOW, it is given a string which provides all of the information
    necessary to identify some unique Turing Machine. So while a TM
    cannot take a Turing Machine as an input, it can still answer
    questions about Turing Machines.


    It is not actually answering the question about a Turing machine.
    It is answering the question about the Turing machine specified by >>>>>> the finite string, this distinction is crucial, and even Linz
    missed it.

    The Turing Machine specified by the finite string *is* a Turing
    Machine, so yes it is answering the question about a Turing Machine.

    Can I take your silence here as an acknowledgment that what you had
    written was an error (and a very silly one at that)?

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

    Everyone here (and Linz) believes that the copy of H embedded at
    Ĥ.qx is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. >>>>>> This is off by exactly one level of indirection.

    That's exactly what the copy of H embedded at Ĥ.qx is supposed to
    report on by the very definition of the problem.

    No Comment?

    A halt decider must, *by definition*, be able to determine the
    halting status of *any* arbitrary computation, so if you want to
    claim that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a computation different from Ĥ applied
    to ⟨Ĥ⟩, then you'd better be able to show how that latter
    computation is to be encoded as a finite string.

    So what string, according to you, encodes the computation Ĥ applied >>>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate >>>>> encodings as strings then they are not, in fact, different
    computations at all.

    No Comment?

    I know you've been asked this question before and have consistently
    ignored it. According to a recent post of yours that constitutes
    justification for a repetitive all-caps temper tantrum!


    No decider is ever supposed to report on the behavior of the
    computation that contains its actual self. Deciders only report on >>>>>> the behavior specified by Turing machine descriptions.

    No, it is supposed to report on the halting status of the
    computation represented by its input. But nothing in the definition
    of 'halt decider' precludes it from being given a description of a
    computation which contains its actual self. If it can't answer
    about that question, then it isn't meeting the definition of a halt
    decider which must be able to answer about *any* computation. And
    in the Linz proof this is precisely what the input specifies, your
    nonsense about the input being a string rather than an actual
    Turing Machine notwithstanding.

    Again, is your silence a recognition that you know see your error?


    That's a fairly fundamental concept in computational theory which >>>>>>> you seem determined to not understand.

    Turing Machines only deal with strings. This means that a
    function can only be computed if (as a minimal requirement) the
    elements of that domain can be ENCODED as strings. If you can
    encoded elements of some domain as strings, then it might be
    possible for a TM to compute that function EVEN WHEN THOSE
    ELEMENTS ARE NOT THEMSELVES STRINGS.

    Integers are not strings, but many functions from integers to
    integers are computable by virtue of the fact that it is
    trivially easy to devise ways of encoding integers as strings.

    Functions from reals to reals, on the other hand, are not going
    to be computable precisely because the overwhelming majority of
    real numbers cannot be encoded as finite strings. A function like >>>>>>> y = √x is not computable, but one can compute some function that >>>>>>> is "close" to this but that limits the input/output to some
    arbitary degree of precision.

    The set of Turing Machines is provably DENUMERABLE. That means
    that one can encode TMs as finite strings. Which in turn means
    that a TM *can* answer questions about Turing Machines. They just >>>>>>> have to be encoded as finite strings before being given to a
    Turing Machine.

    Strings which encode Turing Machines and inputs don't halt
    anymore than strings which encode integers have sums.

    The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never
    reaches its final state of ⟨Ĥ⟩.qn in any finite number of
    correctly simulated steps by the copy of H embedded at Ĥ.qx.

    Finite string pairs don't *have* final states.

    Simulated finite string pairs ⟨Ĥ⟩ ⟨Ĥ⟩ have final states that can >>>> either be reached in a finite number of simulated steps or not.


    I am ignoring all of your other points because this single point is
    the crux of the whole issue and all the other points are tangential.

    Yes, that always seems to be your excuse. Every time anyone raises an objection you ignore it by declaring it 'tangential' and then claim that
    no one has ever presented you with objections. Unfortunately, you have a
    poor track record when it comes to deciding which things are tangential.

    The *simulation* has states which may include final states. The
    string itself does not.

    A BASIC program that is executed in an interpreter is correctly
    construed as reaching its final state.

    10 PRINT "Hello, World!"
    20 END

    ⟨Ĥ⟩ ⟨Ĥ⟩ is executed within the simulator of the copy of H embedded >> within Ĥ. This embedded_H has all of the functionality of a UTM along
    with additional functionality.

    The exact same string $ might encode a Turing Machine when passed to one Turing Machine, an algebraic equation when passed to another TM, and a
    line of Old Church Slavonic written in Glogolitic to a third.


    None-the-less when a BASIC interpreter is running a BASIC program or a simulating halt decider with UTM functionality is simulating a Turing
    machine description in each of these two cases their input would either
    reach or fail to reach a final state.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    The above repeating pattern shows that the correctly simulated input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively proving that this simulated input never halts. This enables embedded_H
    to abort its simulation and correctly transition to Ĥ.qn.




    --
    Copyright 2021 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 All on Mon Mar 14 20:40:10 2022
    XPost: comp.theory

    On 3/14/2022 8:34 PM, André G. Isaak wrote:
    On 2022-03-14 19:17, olcott wrote:
    On 3/12/2022 8:30 PM, André G. Isaak wrote:

    The exact same string $ might encode a Turing Machine when passed to
    one Turing Machine, an algebraic equation when passed to another TM,
    and a line of Old Church Slavonic written in Glogolitic to a third.


    None-the-less when a BASIC interpreter is running a BASIC program or a
    simulating halt decider with UTM functionality is simulating a Turing
    machine description in each of these two cases their input would
    either reach or fail to reach a final state.

    The input to a BASIC interpreter is a string representing a BASIC
    program. The BASIC program might do any number of things including
    reaching the end of the program, but the string itself does not do these things.


    The interpreted BASIC program does run and the simulated Turing machine description does have final states.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Mon Mar 14 20:37:46 2022
    XPost: comp.theory

    On 3/12/2022 9:59 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    I've shown you how to write Linz's conditions in terms of simulation:

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.

    Feel fee to replace "halts" with "would reach its final state" (and
    similarly for "does not halt") if it make you feel better. Both figures
    of speech convey the same mathematical fact, but one is shorter and fits
    on a line.

    What you can't do, if you want to keep talking about what Linz is
    talking about, is replace the reference to a UTM with embedded_H.

    Embedded_H has a full UTM as a part of it. The Linz ⊢* wild card state transition allows for a UTM simulation to be a part of the decision
    process.

    Embedded_H determines whether or not its simulated input would ever
    reach its final state if embedded_H remained in pure UTM mode.

    It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the
    copy of H embedded within Ĥ would never reach the final state of this
    input ⟨Ĥ⟩.qn.

    Irrelevant. What matters is what follows logically from Linz's
    definition of a halt decider. If you think there is any point, I'll
    write it out again for you in terms of UTMs.


    If the input to embedded_H never halts and embedded_H correctly reports
    this that is most relevant.


    --
    Copyright 2021 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 All on Mon Mar 14 21:02:43 2022
    XPost: comp.theory

    On 3/14/2022 8:46 PM, André G. Isaak wrote:
    On 2022-03-14 19:40, olcott wrote:
    On 3/14/2022 8:34 PM, André G. Isaak wrote:
    On 2022-03-14 19:17, olcott wrote:
    On 3/12/2022 8:30 PM, André G. Isaak wrote:

    The exact same string $ might encode a Turing Machine when passed
    to one Turing Machine, an algebraic equation when passed to another
    TM, and a line of Old Church Slavonic written in Glogolitic to a
    third.


    None-the-less when a BASIC interpreter is running a BASIC program or
    a simulating halt decider with UTM functionality is simulating a
    Turing machine description in each of these two cases their input
    would either reach or fail to reach a final state.

    The input to a BASIC interpreter is a string representing a BASIC
    program. The BASIC program might do any number of things including
    reaching the end of the program, but the string itself does not do
    these things.


    The interpreted BASIC program does run and the simulated Turing
    machine description does have final states.

    The interpreted BASIC program is not the same thing as the string which
    is the input to the BASIC interpreter. It's what happens *inside* the interpreter. You don't seem to grasp what "string" means.


    That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when correctly
    simulated by the UTM within embedded_H is the same as these finite
    strings specifying non-halting behavior when correctly interpreted by a
    BASIC in interpreter.

    10 PRINT "Hello, World!"
    20 goto 10
    30 END

    --
    Copyright 2021 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 All on Mon Mar 14 22:07:01 2022
    XPost: comp.theory

    On 3/14/2022 9:05 PM, André G. Isaak wrote:
    On 2022-03-14 20:02, olcott wrote:

    <snip nonresponsive post>

    Again, I'll repeat the question which you dishonestly snipped rather
    than answering. I won't bother putting it in all caps or repeating it
    five times.

    How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?


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

    The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect reference
    away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.


    If there are computations which cannot be encoded as strings, then it is impossible to design a universal halt decider since that means there are computations which it cannot be asked about.

    André



    --
    Copyright 2021 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 Malcolm McLean on Tue Mar 15 09:51:34 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/15/2022 6:35 AM, Malcolm McLean wrote:
    On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
    On 2022-03-14 21:07, olcott wrote:
    On 3/14/2022 9:05 PM, André G. Isaak wrote:
    On 2022-03-14 20:02, olcott wrote:

    <snip nonresponsive post>

    Again, I'll repeat the question which you dishonestly snipped rather
    than answering. I won't bother putting it in all caps or repeating it
    five times.

    How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed >>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>

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

    The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect reference
    away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this >>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
    There are no 'levels of indirection' when discussing Turing Machines.

    If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an input
    to your decider, then your decider is broken since it must be able to
    provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.

    Though that would actually be a genuine contribution to computer science.
    If you could devise a language such that a large subset of halting and non-halting machines could be described, but not machines for which the halting status is difficult or impossible for a predefined halt decider to determine.

    André does not seem to be able to comprehend that a Turing machine
    decider cannot possibly have its own self or an encoding of its own self
    as its input. The closest thing possible that it can have is an encoding
    of another different instance of itself.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    In the case above ⟨Ĥ⟩ ⟨Ĥ⟩ is exactly one level of indirect reference away from Ĥ applied to ⟨Ĥ⟩. The copy of H embedded at Ĥ.qx is not deciding the halt status of its own self (the exact same instance) it is deciding the halt status of a different instance.

    That neither André, Ben nor Richard can comprehend this does not
    indicate that I am incorrect.

    --
    Copyright 2021 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 Malcolm McLean on Tue Mar 15 11:11:04 2022
    XPost: comp.theory

    On 3/15/2022 10:44 AM, Malcolm McLean wrote:
    On Tuesday, 15 March 2022 at 14:51:44 UTC, olcott wrote:
    On 3/15/2022 6:35 AM, Malcolm McLean wrote:
    On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
    On 2022-03-14 21:07, olcott wrote:
    On 3/14/2022 9:05 PM, André G. Isaak wrote:
    On 2022-03-14 20:02, olcott wrote:

    <snip nonresponsive post>

    Again, I'll repeat the question which you dishonestly snipped rather >>>>>> than answering. I won't bother putting it in all caps or repeating it >>>>>> five times.

    How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
    to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>>>

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

    The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect reference
    away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
    exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
    There are no 'levels of indirection' when discussing Turing Machines.

    If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an input
    to your decider, then your decider is broken since it must be able to
    provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.

    Though that would actually be a genuine contribution to computer science. >>> If you could devise a language such that a large subset of halting and
    non-halting machines could be described, but not machines for which the
    halting status is difficult or impossible for a predefined halt decider to determine.
    André does not seem to be able to comprehend that a Turing machine
    decider cannot possibly have its own self or an encoding of its own self
    as its input. The closest thing possible that it can have is an encoding
    of another different instance of itself.

    So how would you describe a compiler which is "bootstrapped", i.e. fed its own
    source code?

    A compiler that is fed its own source-code is not the same because the
    compiler does not execute this source-code.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeff Barnett@21:1/5 to olcott on Tue Mar 15 12:58:36 2022
    XPost: comp.theory

    On 3/15/2022 10:11 AM, olcott wrote:
    On 3/15/2022 10:44 AM, Malcolm McLean wrote:

    <MAJOR SNIP>

    So how would you describe a compiler which is "bootstrapped", i.e. fed
    its own
    source code?

    A compiler that is fed its own source-code is not the same because the compiler does not execute this source-code.
    This is one of your best Peter. Along the way you've had 100s of
    messages that have said that simulation as a basis for a Halting Problem solution is hopeless. Of course you pay no attention because it's
    unlikely you understood what you were being told. So here you are
    looping back over years of the same bone headed approach.

    Let's start with a few basics:

    Nothing executes source code; even an interpreter ingests it first.

    All an ingestor, compiler, or assembler does is to change a program
    languages representation into another equivalent form. If it's working properly, that is.

    So the properly compiled compiler is just another representation of its
    source code. And, indeed, that brings us to the conclusion of this
    little explanation:

    THE COMPILER IN ONE REPRESENTATION IS PROCESSING ITSELF IN ANOTHER REPRESENTATION. SO YOU ARE WRONG ONCE AGAIN (AS ALWAYS).

    Before leaving you to your hard won state as a total proud ignoramus,
    I'll list these terms in the above that you don't understand:

    simulation, Halting Problem, source code, interpreter, ingest, compiler, assembler, equivalent form, representation, ignoramus.

    Quite a list isn't it? Start with "ignoramus" if you want that to go
    away, look it up. Then go through the other words one at a time. Ben has offered, many many times, to teach you if you ask. Why not? Your legacy
    and impression on the world has turned from proud ignorance to
    stupidity. The former is curable, the latter is not. Get busy and leave
    a good impression!
    --
    Jeff Barnett

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Jeff Barnett on Tue Mar 15 14:44:29 2022
    XPost: comp.theory

    On 3/15/2022 1:58 PM, Jeff Barnett wrote:
    On 3/15/2022 10:11 AM, olcott wrote:
    On 3/15/2022 10:44 AM, Malcolm McLean wrote:

       <MAJOR SNIP>

    So how would you describe a compiler which is "bootstrapped", i.e.
    fed its own
    source code?

    A compiler that is fed its own source-code is not the same because the
    compiler does not execute this source-code.
    This is one of your best Peter. Along the way you've had 100s of
    messages that have said that simulation as a basis for a Halting Problem solution is hopeless. Of course you pay no attention because it's
    unlikely you understood what you were being told. So here you are
    looping back over years of the same bone headed approach.

    Let's start with a few basics:

    Nothing executes source code; even an interpreter ingests it first.


    A compiler the compiles its own source-code is nothing at all like
    executing this source code.

    An interpreter that interprets source code can be reasonably construed
    as running this source code.

    When a BASIC programmer says that they ran their program they do not
    provide all of the tedious details of the technical intermediate steps.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeff Barnett@21:1/5 to All on Tue Mar 15 15:48:17 2022
    XPost: comp.theory, sci.logic

    T24gMy8xNS8yMDIyIDE6NDQgUE0sIG9sY290dCB3cm90ZToNCj4gT24gMy8xNS8yMDIyIDE6 NTggUE0sIEplZmYgQmFybmV0dCB3cm90ZToNCj4+IE9uIDMvMTUvMjAyMiAxMDoxMSBBTSwg b2xjb3R0IHdyb3RlOg0KPj4+IE9uIDMvMTUvMjAyMiAxMDo0NCBBTSwgTWFsY29sbSBNY0xl YW4gd3JvdGU6DQo+Pg0KPj4gwqDCoMKgIDxNQUpPUiBTTklQPg0KPj4NCj4+Pj4gU28gaG93 IHdvdWxkIHlvdSBkZXNjcmliZSBhIGNvbXBpbGVyIHdoaWNoIGlzICJib290c3RyYXBwZWQi LCBpLmUuIA0KPj4+PiBmZWQgaXRzIG93bg0KPj4+PiBzb3VyY2UgY29kZT8NCj4+Pg0KPj4+ IEEgY29tcGlsZXIgdGhhdCBpcyBmZWQgaXRzIG93biBzb3VyY2UtY29kZSBpcyBub3QgdGhl IHNhbWUgYmVjYXVzZSANCj4+PiB0aGUgY29tcGlsZXIgZG9lcyBub3QgZXhlY3V0ZSB0aGlz IHNvdXJjZS1jb2RlLg0KPj4gVGhpcyBpcyBvbmUgb2YgeW91ciBiZXN0IFBldGVyLiBBbG9u ZyB0aGUgd2F5IHlvdSd2ZSBoYWQgMTAwcyBvZiANCj4+IG1lc3NhZ2VzIHRoYXQgaGF2ZSBz YWlkIHRoYXQgc2ltdWxhdGlvbiBhcyBhIGJhc2lzIGZvciBhIEhhbHRpbmcgDQo+PiBQcm9i bGVtIHNvbHV0aW9uIGlzIGhvcGVsZXNzLiBPZiBjb3Vyc2UgeW91IHBheSBubyBhdHRlbnRp b24gYmVjYXVzZSANCj4+IGl0J3MgdW5saWtlbHkgeW91IHVuZGVyc3Rvb2Qgd2hhdCB5b3Ug d2VyZSBiZWluZyB0b2xkLiBTbyBoZXJlIHlvdSBhcmUgDQo+PiBsb29waW5nIGJhY2sgb3Zl ciB5ZWFycyBvZiB0aGUgc2FtZSBib25lIGhlYWRlZCBhcHByb2FjaC4NCj4+DQo+PiBMZXQn cyBzdGFydCB3aXRoIGEgZmV3IGJhc2ljczoNCj4+DQo+PiBOb3RoaW5nIGV4ZWN1dGVzIHNv dXJjZSBjb2RlOyBldmVuIGFuIGludGVycHJldGVyIGluZ2VzdHMgaXQgZmlyc3QuDQo+Pg0K PiANCj4gQSBjb21waWxlciB0aGUgY29tcGlsZXMgaXRzIG93biBzb3VyY2UtY29kZSBpcyBu b3RoaW5nIGF0IGFsbCBsaWtlIA0KPiBleGVjdXRpbmcgdGhpcyBzb3VyY2UgY29kZS4NCg0K WW91IHJlYWxseSBkbyBoYXZlIHJvY2tzIGluIHlvdXIgaGVhZC4gVGhpbmsgZm9yIGF0IGxl YXN0IDIgc2Vjb25kcyANCmJlZm9yZSByZXNwb25kaW5nIGFuZCBnZXR0aW5nIGl0IGFsbCB3 cm9uZy4gVGhlIG1pc3Rha2VzIHlvdSBhcmUgbWFraW5nIA0Kd2l0aCB0aGUgYWJvdmUgc3Rh dGVtZW50IGFyZSBzbyBiYXNpYyB0aGF0IEkgaGFyZGx5IGtub3cgd2hlcmUgdG8gc3RhcnQu IA0KQXMgSSd2ZSBiZWVuIHRvbGQgbWFueSB0aW1lcyBpdCdzIGhhcmRlciB0byB0ZWFjaCBL aW5kZXJnYXJ0ZW4gdGhhbiBncmFkIA0Kc3R1ZGVudHMuIEFuZCBpbiB0aGlzIGluc3RhbmNl LCB3aXRoIHlvdSwgd2UgaGF2ZSBhIHNpeHR5IHllYXIgb2xkIA0KY3Jhd2xpbmcgYXJvdW5k IGluIGRpYXBlcnMuDQoNCj4gQW4gaW50ZXJwcmV0ZXIgdGhhdCBpbnRlcnByZXRzIHNvdXJj ZSBjb2RlIGNhbiBiZSByZWFzb25hYmx5IGNvbnN0cnVlZCANCj4gYXMgcnVubmluZyB0aGlz IHNvdXJjZSBjb2RlLg0KDQpQZXJoYXBzLiBUaGUgaXNzdWUgaXMgaXQgcmVhbGx5IGRvZXNu J3Qga25vdyB0aGF0IGl0IGlzIGl0J3Mgb3duIHNvdXJjZSANCmNvZGUsIGRvZXMgaXQ/IEFu ZCwgaW4gZmFjdCwgbmVpdGhlciBpdCBub3IgYW55IG9ic2VydmVyIGlzIGF3YXJlIG9mIGFu eSANCnZpY2lvdXMgc2VsZiByZWZlcmVuY2UuIE9ubHkgYSBkdW5jZSB3b3VsZCB3b3JyeSBh Ym91dCBpdC4gWW91IGRvIHdvcnJ5IA0KZG9uJ3QgeW91Pw0KDQo+IFdoZW4gYSBCQVNJQyBw cm9ncmFtbWVyIHNheXMgdGhhdCB0aGV5IHJhbiB0aGVpciBwcm9ncmFtIHRoZXkgZG8gbm90 IA0KPiBwcm92aWRlIGFsbCBvZiB0aGUgdGVkaW91cyBkZXRhaWxzIG9mIHRoZSB0ZWNobmlj YWwgaW50ZXJtZWRpYXRlIHN0ZXBzLg0KQ2VydGFpbmx5IG5vdCB3aGVuIHRoZXkgcnVuIGl0 LiBCdXQgdGVkaW91cyBkZXRhaWxzIGFyZSBvZnRlbiB0aGUgcmlnaHQgDQppbmZvcm1hdGlv biB3aGVuIHRoZXkgd2FudCB0byBkZXNjcmliZSBpdCBvciBwcm92ZSBzb21ldGhpbmcgYWJv dXQgb3IgDQpkZWJ1ZyBpdCwgZXRjLg0KDQpBbmQgdGhlbiB0aGVyZSdzIHlvdSEgWW91IGZv d2xlZCAoTGlrZSB0aGUgc3BlbGxpbmc/IFRoaW5rIGJpcmQgc2hpdC4pIA0KdXAgYWdhaW4g Ynkgc2xpY2luZyBpbXBvcnRhbnQgYW5kIGhlbHBmdWwgdGV4dCBmcm9tIHRoZSBtZXNzYWdl IHlvdSBhcmUgDQpyZXBseWluZyB0by4gV2FzIGl0IGJlY2F1c2UgaXQgd2Fzbid0IHJlbGV2 YW50PyBObyEgSXQgd2FzIGJlY2F1c2UgeW91IA0KZGltbHkgcGVyY2VpdmVkIHRoYXQgeW91 ciBtaW5kbGVzcyByZXNwb25zZSB3YXMgYWxyZWFkeSBhZGRyZXNzZWQuIFdoeSANCmFkdmVy dGlzZSB0aGF0IHlvdSBhcmUgYSBmcmVha2luZyBpZGlvdCB3aG8gZG9lcyBub3QgcmVhZCBt dWNoIGFuZCBjYW4gDQpub3QgcmVhZCBmb3IgY29tcHJlaGVuc2lvbj8NCg0KVGFrZSB0aGUg YWR2aWNlIGdpdmVuIGluIHRoZSBwYXJ0IHlvdSBjaG9wcGVkIG9mZjogYXNrIEJlbiBmb3Ig aGVscCB0byANCnVuZGVyc3RhbmQgYmFzaWMgdm9jYWJ1bGFyeSBhbmQgY29uY2VwdHMgdGhl biBnbyBmcm9tIHRoZXJlPw0KDQoNCkluIGNhc2UgYW55b25lIGNhcmVzLCB0aGUgb3JpZ2lu YWwgbWVzc2FnZSB0aGF0IFBPIHJlcGxpZWQgdG8sIHdoaWxlIA0Kc29pbGluZyBoaXMgcGFu dHMsIGZvbGxvd3M6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9uIDMvMTUvMjAyMiAxMDoxMSBBTSwg b2xjb3R0IHdyb3RlOg0KID4gT24gMy8xNS8yMDIyIDEwOjQ0IEFNLCBNYWxjb2xtIE1jTGVh biB3cm90ZToNCg0KICAgIDxNQUpPUiBTTklQPg0KDQogPj4gU28gaG93IHdvdWxkIHlvdSBk ZXNjcmliZSBhIGNvbXBpbGVyIHdoaWNoIGlzICJib290c3RyYXBwZWQiLCBpLmUuIA0KZmVk IGl0cyBvd24NCiA+PiBzb3VyY2UgY29kZT8NCiA+DQogPiBBIGNvbXBpbGVyIHRoYXQgaXMg ZmVkIGl0cyBvd24gc291cmNlLWNvZGUgaXMgbm90IHRoZSBzYW1lIGJlY2F1c2UgDQp0aGUg Y29tcGlsZXIgZG9lcyBub3QgZXhlY3V0ZSB0aGlzIHNvdXJjZS1jb2RlLg0KVGhpcyBpcyBv bmUgb2YgeW91ciBiZXN0IFBldGVyLiBBbG9uZyB0aGUgd2F5IHlvdSd2ZSBoYWQgMTAwcyBv ZiANCm1lc3NhZ2VzIHRoYXQgaGF2ZSBzYWlkIHRoYXQgc2ltdWxhdGlvbiBhcyBhIGJhc2lz IGZvciBhIEhhbHRpbmcgUHJvYmxlbSANCnNvbHV0aW9uIGlzIGhvcGVsZXNzLiBPZiBjb3Vy c2UgeW91IHBheSBubyBhdHRlbnRpb24gYmVjYXVzZSBpdCdzIA0KdW5saWtlbHkgeW91IHVu ZGVyc3Rvb2Qgd2hhdCB5b3Ugd2VyZSBiZWluZyB0b2xkLiBTbyBoZXJlIHlvdSBhcmUgDQps b29waW5nIGJhY2sgb3ZlciB5ZWFycyBvZiB0aGUgc2FtZSBib25lIGhlYWRlZCBhcHByb2Fj aC4NCg0KTGV0J3Mgc3RhcnQgd2l0aCBhIGZldyBiYXNpY3M6DQoNCk5vdGhpbmcgZXhlY3V0 ZXMgc291cmNlIGNvZGU7IGV2ZW4gYW4gaW50ZXJwcmV0ZXIgaW5nZXN0cyBpdCBmaXJzdC4N Cg0KQWxsIGFuIGluZ2VzdG9yLCBjb21waWxlciwgb3IgYXNzZW1ibGVyIGRvZXMgaXMgdG8g Y2hhbmdlIGEgcHJvZ3JhbSANCmxhbmd1YWdlcyByZXByZXNlbnRhdGlvbiBpbnRvIGFub3Ro ZXIgZXF1aXZhbGVudCBmb3JtLiBJZiBpdCdzIHdvcmtpbmcgDQpwcm9wZXJseSwgdGhhdCBp cy4NCg0KU28gdGhlIHByb3Blcmx5IGNvbXBpbGVkIGNvbXBpbGVyIGlzIGp1c3QgYW5vdGhl ciByZXByZXNlbnRhdGlvbiBvZiBpdHMgDQpzb3VyY2UgY29kZS4gQW5kLCBpbmRlZWQsIHRo YXQgYnJpbmdzIHVzIHRvIHRoZSBjb25jbHVzaW9uIG9mIHRoaXMgDQpsaXR0bGUgZXhwbGFu YXRpb246DQoNClRIRSBDT01QSUxFUiBJTiBPTkUgUkVQUkVTRU5UQVRJT04gSVMgUFJPQ0VT U0lORyBJVFNFTEYgSU4gQU5PVEhFUiANClJFUFJFU0VOVEFUSU9OLiBTTyBZT1UgQVJFIFdS T05HIE9OQ0UgQUdBSU4gKEFTIEFMV0FZUykuDQoNCkJlZm9yZSBsZWF2aW5nIHlvdSB0byB5 b3VyIGhhcmQgd29uIHN0YXRlIGFzIGEgdG90YWwgcHJvdWQgaWdub3JhbXVzLCANCkknbGwg bGlzdCB0aGVzZSB0ZXJtcyBpbiB0aGUgYWJvdmUgdGhhdCB5b3UgZG9uJ3QgdW5kZXJzdGFu ZDoNCg0Kc2ltdWxhdGlvbiwgSGFsdGluZyBQcm9ibGVtLCBzb3VyY2UgY29kZSwgaW50ZXJw cmV0ZXIsIGluZ2VzdCwgY29tcGlsZXIsIA0KYXNzZW1ibGVyLCBlcXVpdmFsZW50IGZvcm0s IHJlcHJlc2VudGF0aW9uLCBpZ25vcmFtdXMuDQoNClF1aXRlIGEgbGlzdCBpc24ndCBpdD8g U3RhcnQgd2l0aCAiaWdub3JhbXVzIiBpZiB5b3Ugd2FudCB0aGF0IHRvIGdvIA0KYXdheSwg bG9vayBpdCB1cC4gVGhlbiBnbyB0aHJvdWdoIHRoZSBvdGhlciB3b3JkcyBvbmUgYXQgYSB0 aW1lLiBCZW4gaGFzIA0Kb2ZmZXJlZCwgbWFueSBtYW55IHRpbWVzLCB0byB0ZWFjaCB5b3Ug aWYgeW91IGFzay4gV2h5IG5vdD8gWW91ciBsZWdhY3kgDQphbmQgaW1wcmVzc2lvbiBvbiB0 aGUgd29ybGQgaGFzIHR1cm5lZCBmcm9tIHByb3VkIGlnbm9yYW5jZSB0byANCnN0dXBpZGl0 eS4gVGhlIGZvcm1lciBpcyBjdXJhYmxlLCB0aGUgbGF0dGVyIGlzIG5vdC4gR2V0IGJ1c3kg YW5kIGxlYXZlIA0KYSBnb29kIGltcHJlc3Npb24hDQotLSANCkplZmYgQmFybmV0dA0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Jeff Barnett on Tue Mar 15 17:02:46 2022
    XPost: comp.theory, sci.logic

    On 3/15/2022 4:48 PM, Jeff Barnett wrote:
    On 3/15/2022 1:44 PM, olcott wrote:
    On 3/15/2022 1:58 PM, Jeff Barnett wrote:
    On 3/15/2022 10:11 AM, olcott wrote:
    On 3/15/2022 10:44 AM, Malcolm McLean wrote:

        <MAJOR SNIP>

    So how would you describe a compiler which is "bootstrapped", i.e.
    fed its own
    source code?

    A compiler that is fed its own source-code is not the same because
    the compiler does not execute this source-code.
    This is one of your best Peter. Along the way you've had 100s of
    messages that have said that simulation as a basis for a Halting
    Problem solution is hopeless. Of course you pay no attention because
    it's unlikely you understood what you were being told. So here you
    are looping back over years of the same bone headed approach.

    Let's start with a few basics:

    Nothing executes source code; even an interpreter ingests it first.


    A compiler the compiles its own source-code is nothing at all like
    executing this source code.

    You really do have rocks in your head. Think for at least 2 seconds
    before responding and getting it all wrong. The mistakes you are making
    with the above statement are so basic that I hardly know where to start.
    As I've been told many times it's harder to teach Kindergarten than grad students. And in this instance, with you, we have a sixty year old
    crawling around in diapers.

    An interpreter that interprets source code can be reasonably construed
    as running this source code.

    Perhaps. The issue is it really doesn't know that it is it's own source
    code, does it? And, in fact, neither it nor any observer is aware of any vicious self reference. Only a dunce would worry about it. You do worry
    don't you?

    In other words you are saying that no one is bright enough to be able to
    detect what is essentially infinite recursion.

    --
    Copyright 2021 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 All on Tue Mar 15 16:44:02 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/15/2022 3:24 PM, André G. Isaak wrote:
    On 2022-03-15 08:51, olcott wrote:
    On 3/15/2022 6:35 AM, Malcolm McLean wrote:
    On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
    On 2022-03-14 21:07, olcott wrote:
    On 3/14/2022 9:05 PM, André G. Isaak wrote:
    On 2022-03-14 20:02, olcott wrote:

    <snip nonresponsive post>

    Again, I'll repeat the question which you dishonestly snipped rather >>>>>> than answering. I won't bother putting it in all caps or repeating it >>>>>> five times.

    How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
    to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>>>

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

    The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect >>>>> reference
    away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
    exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
    There are no 'levels of indirection' when discussing Turing Machines.

    If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an >>>> input
    to your decider, then your decider is broken since it must be able to
    provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.

    Though that would actually be a genuine contribution to computer
    science.
    If you could devise a language such that a large subset of halting and
    non-halting machines could be described, but not machines for which the
    halting status is difficult or impossible for a predefined halt
    decider to determine.

    André does not seem to be able to comprehend that a Turing machine
    decider cannot possibly have its own self or an encoding of its own
    self as its input. The closest thing possible that it can have is an
    encoding of another different instance of itself.

    Computations don't have different instances. What would it even mean to 'instantiate' a computation?

    André


    A Turing machine UTM that is simulating its own Turing machine
    description is two distinct instances: (executed and simulated) even if computer science does not bother to pay attention to this level of
    detail, or have the terminology to express it.

    --
    Copyright 2021 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 All on Tue Mar 15 20:15:31 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/15/2022 3:24 PM, André G. Isaak wrote:
    On 2022-03-15 08:51, olcott wrote:
    On 3/15/2022 6:35 AM, Malcolm McLean wrote:
    On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
    On 2022-03-14 21:07, olcott wrote:
    On 3/14/2022 9:05 PM, André G. Isaak wrote:
    On 2022-03-14 20:02, olcott wrote:

    <snip nonresponsive post>

    Again, I'll repeat the question which you dishonestly snipped rather >>>>>> than answering. I won't bother putting it in all caps or repeating it >>>>>> five times.

    How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
    to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>>>

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

    The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect >>>>> reference
    away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
    exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
    There are no 'levels of indirection' when discussing Turing Machines.

    If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an >>>> input
    to your decider, then your decider is broken since it must be able to
    provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.

    Though that would actually be a genuine contribution to computer
    science.
    If you could devise a language such that a large subset of halting and
    non-halting machines could be described, but not machines for which the
    halting status is difficult or impossible for a predefined halt
    decider to determine.

    André does not seem to be able to comprehend that a Turing machine
    decider cannot possibly have its own self or an encoding of its own
    self as its input. The closest thing possible that it can have is an
    encoding of another different instance of itself.

    Computations don't have different instances. What would it even mean to 'instantiate' a computation?

    André


    Back to the key point:

    That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when correctly
    simulated by the UTM within embedded_H is the same as these finite
    strings specifying non-halting behavior when correctly interpreted by a
    BASIC in interpreter.

    10 PRINT "Hello, World!"
    20 goto 10
    30 END

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    The above repeating pattern shows that the correctly simulated input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively proving that this simulated input never halts. This enables embedded_H
    to abort its simulation and correctly transition to Ĥ.qn.


    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeff Barnett@21:1/5 to All on Wed Mar 16 01:21:48 2022
    XPost: comp.theory, sci.logic

    T24gMy8xNS8yMDIyIDQ6MDIgUE0sIG9sY290dCB3cm90ZToNCj4gT24gMy8xNS8yMDIyIDQ6 NDggUE0sIEplZmYgQmFybmV0dCB3cm90ZToNCj4+IE9uIDMvMTUvMjAyMiAxOjQ0IFBNLCBv bGNvdHQgd3JvdGU6DQo+Pj4gT24gMy8xNS8yMDIyIDE6NTggUE0sIEplZmYgQmFybmV0dCB3 cm90ZToNCj4+Pj4gT24gMy8xNS8yMDIyIDEwOjExIEFNLCBvbGNvdHQgd3JvdGU6DQo+Pj4+ PiBPbiAzLzE1LzIwMjIgMTA6NDQgQU0sIE1hbGNvbG0gTWNMZWFuIHdyb3RlOg0KPj4+Pg0K Pj4+PiDCoMKgwqAgPE1BSk9SIFNOSVA+DQo+Pj4+DQo+Pj4+Pj4gU28gaG93IHdvdWxkIHlv dSBkZXNjcmliZSBhIGNvbXBpbGVyIHdoaWNoIGlzICJib290c3RyYXBwZWQiLCBpLmUuIA0K Pj4+Pj4+IGZlZCBpdHMgb3duDQo+Pj4+Pj4gc291cmNlIGNvZGU/DQo+Pj4+Pg0KPj4+Pj4g QSBjb21waWxlciB0aGF0IGlzIGZlZCBpdHMgb3duIHNvdXJjZS1jb2RlIGlzIG5vdCB0aGUg c2FtZSBiZWNhdXNlIA0KPj4+Pj4gdGhlIGNvbXBpbGVyIGRvZXMgbm90IGV4ZWN1dGUgdGhp cyBzb3VyY2UtY29kZS4NCj4+Pj4gVGhpcyBpcyBvbmUgb2YgeW91ciBiZXN0IFBldGVyLiBB bG9uZyB0aGUgd2F5IHlvdSd2ZSBoYWQgMTAwcyBvZiANCj4+Pj4gbWVzc2FnZXMgdGhhdCBo YXZlIHNhaWQgdGhhdCBzaW11bGF0aW9uIGFzIGEgYmFzaXMgZm9yIGEgSGFsdGluZyANCj4+ Pj4gUHJvYmxlbSBzb2x1dGlvbiBpcyBob3BlbGVzcy4gT2YgY291cnNlIHlvdSBwYXkgbm8g YXR0ZW50aW9uIGJlY2F1c2UgDQo+Pj4+IGl0J3MgdW5saWtlbHkgeW91IHVuZGVyc3Rvb2Qg d2hhdCB5b3Ugd2VyZSBiZWluZyB0b2xkLiBTbyBoZXJlIHlvdSANCj4+Pj4gYXJlIGxvb3Bp bmcgYmFjayBvdmVyIHllYXJzIG9mIHRoZSBzYW1lIGJvbmUgaGVhZGVkIGFwcHJvYWNoLg0K Pj4+Pg0KPj4+PiBMZXQncyBzdGFydCB3aXRoIGEgZmV3IGJhc2ljczoNCj4+Pj4NCj4+Pj4g Tm90aGluZyBleGVjdXRlcyBzb3VyY2UgY29kZTsgZXZlbiBhbiBpbnRlcnByZXRlciBpbmdl c3RzIGl0IGZpcnN0Lg0KPj4+Pg0KPj4+DQo+Pj4gQSBjb21waWxlciB0aGUgY29tcGlsZXMg aXRzIG93biBzb3VyY2UtY29kZSBpcyBub3RoaW5nIGF0IGFsbCBsaWtlIA0KPj4+IGV4ZWN1 dGluZyB0aGlzIHNvdXJjZSBjb2RlLg0KPj4NCj4+IFlvdSByZWFsbHkgZG8gaGF2ZSByb2Nr cyBpbiB5b3VyIGhlYWQuIFRoaW5rIGZvciBhdCBsZWFzdCAyIHNlY29uZHMgDQo+PiBiZWZv cmUgcmVzcG9uZGluZyBhbmQgZ2V0dGluZyBpdCBhbGwgd3JvbmcuIFRoZSBtaXN0YWtlcyB5 b3UgYXJlIA0KPj4gbWFraW5nIHdpdGggdGhlIGFib3ZlIHN0YXRlbWVudCBhcmUgc28gYmFz aWMgdGhhdCBJIGhhcmRseSBrbm93IHdoZXJlIA0KPj4gdG8gc3RhcnQuIEFzIEkndmUgYmVl biB0b2xkIG1hbnkgdGltZXMgaXQncyBoYXJkZXIgdG8gdGVhY2ggDQo+PiBLaW5kZXJnYXJ0 ZW4gdGhhbiBncmFkIHN0dWRlbnRzLiBBbmQgaW4gdGhpcyBpbnN0YW5jZSwgd2l0aCB5b3Us IHdlIA0KPj4gaGF2ZSBhIHNpeHR5IHllYXIgb2xkIGNyYXdsaW5nIGFyb3VuZCBpbiBkaWFw ZXJzLg0KPj4NCj4+PiBBbiBpbnRlcnByZXRlciB0aGF0IGludGVycHJldHMgc291cmNlIGNv ZGUgY2FuIGJlIHJlYXNvbmFibHkgDQo+Pj4gY29uc3RydWVkIGFzIHJ1bm5pbmcgdGhpcyBz b3VyY2UgY29kZS4NCj4+DQo+PiBQZXJoYXBzLiBUaGUgaXNzdWUgaXMgaXQgcmVhbGx5IGRv ZXNuJ3Qga25vdyB0aGF0IGl0IGlzIGl0J3Mgb3duIA0KPj4gc291cmNlIGNvZGUsIGRvZXMg aXQ/IEFuZCwgaW4gZmFjdCwgbmVpdGhlciBpdCBub3IgYW55IG9ic2VydmVyIGlzIA0KPj4g YXdhcmUgb2YgYW55IHZpY2lvdXMgc2VsZiByZWZlcmVuY2UuIE9ubHkgYSBkdW5jZSB3b3Vs ZCB3b3JyeSBhYm91dCANCj4+IGl0LiBZb3UgZG8gd29ycnkgZG9uJ3QgeW91Pw0KPiANCj4g SW4gb3RoZXIgd29yZHMgeW91IGFyZSBzYXlpbmcgdGhhdCBubyBvbmUgaXMgYnJpZ2h0IGVu b3VnaCB0byBiZSBhYmxlIHRvIA0KPiBkZXRlY3Qgd2hhdCBpcyBlc3NlbnRpYWxseSBpbmZp bml0ZSByZWN1cnNpb24uDQpZb3Ugc29pbGVkIHlvdXIgZGlhcGVycyBhZ2Fpbi4gSSBzYWlk IG5vdGhpbmcgb2YgdGhlIHNvcnQuIEkgd2lsbCBzYXkgaXQgDQpub3cgdGhvdWdoLCBub2Jv ZHkgaXMgaW50ZWxsaWdlbnQgZW5vdWdoIHRvIHN5c3RlbWF0aWNhbGx5IChieSANCmFsZ29y aXRobSkgc3BvdCBpbmZpbml0ZSByZWN1cnNpb24uIEdvZCBjYW4ndCBkbyBpdCBlaXRoZXIu IEl0J3Mgbm90IA0KdGhlb3JldGljYWxseSBwb3NzaWJsZS4gT25seSBhbiBpZ25vcmFudCBu aXR3aXQgd291bGQgbm90IGtub3cgdGhhdCBhbmQgDQpwcmF0dGxlIG9uIGZvciB5ZWFycyBh Ym91dCBpdC4NCg0KQnkgdGhlIHdheSwgaWYgeW91IHRoaW5rIGVpdGhlciB5b3Ugb3IgYSBw cm9ncmFtIHlvdSB3cml0ZSBjYW4gc3BvdCANCmluZmluaXRlIHJlY3Vyc2lvbiBpbiwgc2F5 LCBhIHllYXIgSSdkIGxvdmUgdG8gbWFrZSBhIHNpemFibGUgYmV0IHRoYXQgDQp5b3UgY2Fu IG5vdC4gSW4gdGhlIHBhc3Qgc2V2ZXJhbCBvZiB1cyBoYXZlIHByb3Bvc2VkIHN1Y2ggdGVz dCBjYXNlcyB0byANCnlvdS4gWW91IGhhdmVuJ3QgdHJpZWQgYW55IG9mIHRoZW0uIEluIGZh Y3QgeW91IGNsaXBwZWQgdGhlc2UgcHJvYmxlbSANCmRlc2NyaXB0aW9ucyBvdXQgb2YgdGhl IG9yaWdpbmFsIG1lc3NhZ2VzIHdoZW4geW91IHJlc3BvbmRlZC4NCg0KSXQncyBhbWF6aW5n IHRoYXQgeW91IG1ha2UgdGhlIHNhbWUgbWlzdGFrZXMgb3ZlciBhbmQgb3ZlciBhZ2Fpbi4g SWYgeW91IA0KY291bGQgc3BvdCB0aGUgaW5maW5pdGUgcmVjdXJzaW9uL2l0ZXJhdGlvbiBp biB0aGF0IHNtYWxsIG1pbmQgb2YgeW91cnMgDQp5b3Ugd291bGQgYmUgZG9pbmcgc29tZXRo aW5nIG1vcmUgc2FuZSB3aXRoIHlvdXIgdGltZS4NCi0tIA0KSmVmZiBCYXJuZXR0DQo=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Jeff Barnett on Wed Mar 16 09:15:57 2022
    XPost: comp.theory, sci.logic

    On 3/16/2022 2:21 AM, Jeff Barnett wrote:
    On 3/15/2022 4:02 PM, olcott wrote:
    On 3/15/2022 4:48 PM, Jeff Barnett wrote:
    On 3/15/2022 1:44 PM, olcott wrote:
    On 3/15/2022 1:58 PM, Jeff Barnett wrote:
    On 3/15/2022 10:11 AM, olcott wrote:
    On 3/15/2022 10:44 AM, Malcolm McLean wrote:

        <MAJOR SNIP>

    So how would you describe a compiler which is "bootstrapped",
    i.e. fed its own
    source code?

    A compiler that is fed its own source-code is not the same because >>>>>> the compiler does not execute this source-code.
    This is one of your best Peter. Along the way you've had 100s of
    messages that have said that simulation as a basis for a Halting
    Problem solution is hopeless. Of course you pay no attention
    because it's unlikely you understood what you were being told. So
    here you are looping back over years of the same bone headed approach. >>>>>
    Let's start with a few basics:

    Nothing executes source code; even an interpreter ingests it first.


    A compiler the compiles its own source-code is nothing at all like
    executing this source code.

    You really do have rocks in your head. Think for at least 2 seconds
    before responding and getting it all wrong. The mistakes you are
    making with the above statement are so basic that I hardly know where
    to start. As I've been told many times it's harder to teach
    Kindergarten than grad students. And in this instance, with you, we
    have a sixty year old crawling around in diapers.

    An interpreter that interprets source code can be reasonably
    construed as running this source code.

    Perhaps. The issue is it really doesn't know that it is it's own
    source code, does it? And, in fact, neither it nor any observer is
    aware of any vicious self reference. Only a dunce would worry about
    it. You do worry don't you?

    In other words you are saying that no one is bright enough to be able
    to detect what is essentially infinite recursion.
    You soiled your diapers again. I said nothing of the sort. I will say it
    now though, nobody is intelligent enough to systematically (by
    algorithm) spot infinite recursion. God can't do it either. It's not theoretically possible. Only an ignorant nitwit would not know that and prattle on for years about it.


    I already have a group of many experts that concur that infinite
    recursion can be detected and the criterion measure by which it is
    correctly detected.

    By the way, if you think either you or a program you write can spot
    infinite recursion in, say, a year I'd love to make a sizable bet that
    you can not. In the past several of us have proposed such test cases to
    you. You haven't tried any of them. In fact you clipped these problem descriptions out of the original messages when you responded.

    It's amazing that you make the same mistakes over and over again. If you could spot the infinite recursion/iteration in that small mind of yours
    you would be doing something more sane with your time.


    --
    Copyright 2021 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 Malcolm McLean on Wed Mar 16 11:17:29 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/16/2022 11:06 AM, Malcolm McLean wrote:
    On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:
    On 3/16/2022 2:21 AM, Jeff Barnett wrote:
    On 3/15/2022 4:02 PM, olcott wrote:
    On 3/15/2022 4:48 PM, Jeff Barnett wrote:
    On 3/15/2022 1:44 PM, olcott wrote:
    On 3/15/2022 1:58 PM, Jeff Barnett wrote:
    On 3/15/2022 10:11 AM, olcott wrote:
    On 3/15/2022 10:44 AM, Malcolm McLean wrote:

    <MAJOR SNIP>

    So how would you describe a compiler which is "bootstrapped", >>>>>>>>> i.e. fed its own
    source code?

    A compiler that is fed its own source-code is not the same because >>>>>>>> the compiler does not execute this source-code.
    This is one of your best Peter. Along the way you've had 100s of >>>>>>> messages that have said that simulation as a basis for a Halting >>>>>>> Problem solution is hopeless. Of course you pay no attention
    because it's unlikely you understood what you were being told. So >>>>>>> here you are looping back over years of the same bone headed approach. >>>>>>>
    Let's start with a few basics:

    Nothing executes source code; even an interpreter ingests it first. >>>>>>>

    A compiler the compiles its own source-code is nothing at all like >>>>>> executing this source code.

    You really do have rocks in your head. Think for at least 2 seconds
    before responding and getting it all wrong. The mistakes you are
    making with the above statement are so basic that I hardly know where >>>>> to start. As I've been told many times it's harder to teach
    Kindergarten than grad students. And in this instance, with you, we
    have a sixty year old crawling around in diapers.

    An interpreter that interprets source code can be reasonably
    construed as running this source code.

    Perhaps. The issue is it really doesn't know that it is it's own
    source code, does it? And, in fact, neither it nor any observer is
    aware of any vicious self reference. Only a dunce would worry about
    it. You do worry don't you?

    In other words you are saying that no one is bright enough to be able
    to detect what is essentially infinite recursion.
    You soiled your diapers again. I said nothing of the sort. I will say it >>> now though, nobody is intelligent enough to systematically (by
    algorithm) spot infinite recursion. God can't do it either. It's not
    theoretically possible. Only an ignorant nitwit would not know that and
    prattle on for years about it.

    I already have a group of many experts that concur that infinite
    recursion can be detected and the criterion measure by which it is
    correctly detected.

    It can often be detected.
    In real programs which are basically imperative, with a small amount of recursion,
    written by human programmers, infinite recursion can usually be detected quite easily.

    However it's possible to recast famous open problems in mathematics as recursive routines which either eventualy return or never return, depending on
    whether the conjecture is true or false. Of course you can't detect infinite recursion in these cases by using a simple toolkit of pattern matching.

    Currently undecidable because a proof is currently unknown is not the
    same as "undecidable" because of self contradiction such as the Liar
    Paradox (Upon which the Tarski Undefinability Theorem is based).

    --
    Copyright 2021 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 Malcolm McLean on Wed Mar 16 12:13:51 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/16/2022 11:40 AM, Malcolm McLean wrote:
    On Wednesday, 16 March 2022 at 16:17:38 UTC, olcott wrote:
    On 3/16/2022 11:06 AM, Malcolm McLean wrote:
    On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:
    On 3/16/2022 2:21 AM, Jeff Barnett wrote:
    On 3/15/2022 4:02 PM, olcott wrote:
    On 3/15/2022 4:48 PM, Jeff Barnett wrote:
    On 3/15/2022 1:44 PM, olcott wrote:
    On 3/15/2022 1:58 PM, Jeff Barnett wrote:
    On 3/15/2022 10:11 AM, olcott wrote:
    On 3/15/2022 10:44 AM, Malcolm McLean wrote:

    <MAJOR SNIP>

    So how would you describe a compiler which is "bootstrapped", >>>>>>>>>>> i.e. fed its own
    source code?

    A compiler that is fed its own source-code is not the same because >>>>>>>>>> the compiler does not execute this source-code.
    This is one of your best Peter. Along the way you've had 100s of >>>>>>>>> messages that have said that simulation as a basis for a Halting >>>>>>>>> Problem solution is hopeless. Of course you pay no attention >>>>>>>>> because it's unlikely you understood what you were being told. So >>>>>>>>> here you are looping back over years of the same bone headed approach.

    Let's start with a few basics:

    Nothing executes source code; even an interpreter ingests it first. >>>>>>>>>

    A compiler the compiles its own source-code is nothing at all like >>>>>>>> executing this source code.

    You really do have rocks in your head. Think for at least 2 seconds >>>>>>> before responding and getting it all wrong. The mistakes you are >>>>>>> making with the above statement are so basic that I hardly know where >>>>>>> to start. As I've been told many times it's harder to teach
    Kindergarten than grad students. And in this instance, with you, we >>>>>>> have a sixty year old crawling around in diapers.

    An interpreter that interprets source code can be reasonably
    construed as running this source code.

    Perhaps. The issue is it really doesn't know that it is it's own >>>>>>> source code, does it? And, in fact, neither it nor any observer is >>>>>>> aware of any vicious self reference. Only a dunce would worry about >>>>>>> it. You do worry don't you?

    In other words you are saying that no one is bright enough to be able >>>>>> to detect what is essentially infinite recursion.
    You soiled your diapers again. I said nothing of the sort. I will say it >>>>> now though, nobody is intelligent enough to systematically (by
    algorithm) spot infinite recursion. God can't do it either. It's not >>>>> theoretically possible. Only an ignorant nitwit would not know that and >>>>> prattle on for years about it.

    I already have a group of many experts that concur that infinite
    recursion can be detected and the criterion measure by which it is
    correctly detected.

    It can often be detected.
    In real programs which are basically imperative, with a small amount of recursion,
    written by human programmers, infinite recursion can usually be detected quite easily.

    However it's possible to recast famous open problems in mathematics as
    recursive routines which either eventualy return or never return, depending on
    whether the conjecture is true or false. Of course you can't detect infinite
    recursion in these cases by using a simple toolkit of pattern matching.
    Currently undecidable because a proof is currently unknown is not the
    same as "undecidable" because of self contradiction such as the Liar
    Paradox (Upon which the Tarski Undefinability Theorem is based).

    That's right. For example Goldbach's conjecture is that every even number above
    two is the sum of two primes. If you have a universal infinite recursion detector,
    it would be easy to prove or disprove this conjecture by writing a function which
    terminates when it finds a counterexample, and running it through the detector.
    But of course we can't write a universal infinite recursion detector.


    It does not need to be universal to defeat the halting problem proof counter-example templates. This refutes this whole class of halting
    problem proofs.

    What you might be able to do is write a special purpose detector, and prove or
    disprove the conjecture that way. But you can't do that by using a few simple techniques, or it would have been done already. What's more likely is that the conjecture will be solved by mathematical techniques, and then you could dectect functions which enumerate the conjecture, and decide them based on prior knowledge. However that's difficult to do, and not really of much interest
    to anyone.


    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Mike Terry on Wed Mar 16 12:20:52 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/16/2022 12:04 PM, Mike Terry wrote:
    On 16/03/2022 14:15, olcott wrote:
    On 3/16/2022 2:21 AM, Jeff Barnett wrote:
    On 3/15/2022 4:02 PM, olcott wrote:
    On 3/15/2022 4:48 PM, Jeff Barnett wrote:
    On 3/15/2022 1:44 PM, olcott wrote:
    On 3/15/2022 1:58 PM, Jeff Barnett wrote:
    On 3/15/2022 10:11 AM, olcott wrote:
    On 3/15/2022 10:44 AM, Malcolm McLean wrote:

        <MAJOR SNIP>

    So how would you describe a compiler which is "bootstrapped", >>>>>>>>> i.e. fed its own
    source code?

    A compiler that is fed its own source-code is not the same
    because the compiler does not execute this source-code.
    This is one of your best Peter. Along the way you've had 100s of >>>>>>> messages that have said that simulation as a basis for a Halting >>>>>>> Problem solution is hopeless. Of course you pay no attention
    because it's unlikely you understood what you were being told. So >>>>>>> here you are looping back over years of the same bone headed
    approach.

    Let's start with a few basics:

    Nothing executes source code; even an interpreter ingests it first. >>>>>>>

    A compiler the compiles its own source-code is nothing at all like >>>>>> executing this source code.

    You really do have rocks in your head. Think for at least 2 seconds
    before responding and getting it all wrong. The mistakes you are
    making with the above statement are so basic that I hardly know
    where to start. As I've been told many times it's harder to teach
    Kindergarten than grad students. And in this instance, with you, we
    have a sixty year old crawling around in diapers.

    An interpreter that interprets source code can be reasonably
    construed as running this source code.

    Perhaps. The issue is it really doesn't know that it is it's own
    source code, does it? And, in fact, neither it nor any observer is
    aware of any vicious self reference. Only a dunce would worry about
    it. You do worry don't you?

    In other words you are saying that no one is bright enough to be
    able to detect what is essentially infinite recursion.
    You soiled your diapers again. I said nothing of the sort. I will say
    it now though, nobody is intelligent enough to systematically (by
    algorithm) spot infinite recursion. God can't do it either. It's not
    theoretically possible. Only an ignorant nitwit would not know that
    and prattle on for years about it.


    I already have a group of many experts that concur that infinite
    recursion can be detected and the criterion measure by which it is
    correctly detected.

    I'm afraid that you lack the intellect to understand exactly what other people are saying on technical issues.  How many times have you quoted
    me (and others here) as supporting something you've claimed, whereas it
    turns out you had just misunderstood some remark that had been made?
    [Answer: lots of times!]

    You also have a habit of going elsewhere, and "tricking" the people
    there into "agreeing" with some claim you've made here by not properly explaining the full context of your claim.  Then you come back here selectively quoting some "expert" to suggest he is supporting you.
    [Like when you went to the x86 group and showed them your "trace" asking
    them if they could see what's going on, and got one of them to say "it's looping...".  You failed to mention the trace was not the "processor
    trace" they would naturally expect, and that there was simulation
    involved, and that your trace was in fact some kind of "merged
    simulation trace", and that you were using this trace to disprove the
    Halting Problem theorem.]

    It's been pointed out to you many times that algorithms exhist that can identify /some/ infinite loops/recursions as such, but no algorithm
    detects ALL non-halting behaviour.

    And specifically, your test (looking for more than one call to a
    particular address etc.) is /unsound/ when you try to use it on your
    "merged simulation" trace.  No expert would say otherwise if they had
    been given the full context, so probably you've just tricked someone
    again...


    Mike.

    None-the-less is is self-evident that the input presented to the copy of
    the Linz H embedded at Ĥ.qx does specify infinitely nested simulation to simulating halt decider embedded_H thus proving that a transition to
    Ĥ.qn by embedded_H would be correct.

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
    state of M

    Simulating halt decider H performs a pure simulation of its input as if
    it was a UTM unless and until it detects an infinitely repeating
    pattern. Then it aborts the simulation of its input and transitions to
    its final reject state. Otherwise H transitions to its accept state when
    its simulation ends.

    The following simplifies the syntax for the definition of the Linz
    Turing machine Ĥ, it is now a single machine with a single start state.
    A copy of Linz H is embedded at Ĥ.qx.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its final state.

    https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Mike Terry on Wed Mar 16 14:10:37 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/16/2022 12:37 PM, Mike Terry wrote:
    On 16/03/2022 17:20, olcott wrote:
    On 3/16/2022 12:04 PM, Mike Terry wrote:
    On 16/03/2022 14:15, olcott wrote:
    On 3/16/2022 2:21 AM, Jeff Barnett wrote:
    On 3/15/2022 4:02 PM, olcott wrote:
    On 3/15/2022 4:48 PM, Jeff Barnett wrote:
    On 3/15/2022 1:44 PM, olcott wrote:
    On 3/15/2022 1:58 PM, Jeff Barnett wrote:
    On 3/15/2022 10:11 AM, olcott wrote:
    On 3/15/2022 10:44 AM, Malcolm McLean wrote:

        <MAJOR SNIP>

    So how would you describe a compiler which is "bootstrapped", >>>>>>>>>>> i.e. fed its own
    source code?

    A compiler that is fed its own source-code is not the same >>>>>>>>>> because the compiler does not execute this source-code.
    This is one of your best Peter. Along the way you've had 100s >>>>>>>>> of messages that have said that simulation as a basis for a
    Halting Problem solution is hopeless. Of course you pay no
    attention because it's unlikely you understood what you were >>>>>>>>> being told. So here you are looping back over years of the same >>>>>>>>> bone headed approach.

    Let's start with a few basics:

    Nothing executes source code; even an interpreter ingests it >>>>>>>>> first.


    A compiler the compiles its own source-code is nothing at all
    like executing this source code.

    You really do have rocks in your head. Think for at least 2
    seconds before responding and getting it all wrong. The mistakes >>>>>>> you are making with the above statement are so basic that I
    hardly know where to start. As I've been told many times it's
    harder to teach Kindergarten than grad students. And in this
    instance, with you, we have a sixty year old crawling around in
    diapers.

    An interpreter that interprets source code can be reasonably
    construed as running this source code.

    Perhaps. The issue is it really doesn't know that it is it's own >>>>>>> source code, does it? And, in fact, neither it nor any observer
    is aware of any vicious self reference. Only a dunce would worry >>>>>>> about it. You do worry don't you?

    In other words you are saying that no one is bright enough to be
    able to detect what is essentially infinite recursion.
    You soiled your diapers again. I said nothing of the sort. I will
    say it now though, nobody is intelligent enough to systematically
    (by algorithm) spot infinite recursion. God can't do it either.
    It's not theoretically possible. Only an ignorant nitwit would not
    know that and prattle on for years about it.


    I already have a group of many experts that concur that infinite
    recursion can be detected and the criterion measure by which it is
    correctly detected.

    I'm afraid that you lack the intellect to understand exactly what
    other people are saying on technical issues.  How many times have you
    quoted me (and others here) as supporting something you've claimed,
    whereas it turns out you had just misunderstood some remark that had
    been made? [Answer: lots of times!]

    You also have a habit of going elsewhere, and "tricking" the people
    there into "agreeing" with some claim you've made here by not
    properly explaining the full context of your claim.  Then you come
    back here selectively quoting some "expert" to suggest he is
    supporting you. [Like when you went to the x86 group and showed them
    your "trace" asking them if they could see what's going on, and got
    one of them to say "it's looping...".  You failed to mention the
    trace was not the "processor trace" they would naturally expect, and
    that there was simulation involved, and that your trace was in fact
    some kind of "merged simulation trace", and that you were using this
    trace to disprove the Halting Problem theorem.]

    It's been pointed out to you many times that algorithms exhist that
    can identify /some/ infinite loops/recursions as such, but no
    algorithm detects ALL non-halting behaviour.

    And specifically, your test (looking for more than one call to a
    particular address etc.) is /unsound/ when you try to use it on your
    "merged simulation" trace.  No expert would say otherwise if they had
    been given the full context, so probably you've just tricked someone
    again...


    Mike.

    None-the-less is is self-evident that the input presented to the copy
    of the Linz H embedded at Ĥ.qx does specify infinitely nested
    simulation to simulating halt decider embedded_H thus proving that a
    transition to Ĥ.qn by embedded_H would be correct.

    You mean self-evident TO YOU.  To people who have an understanding of
    TMs it is simply wrong or meaningless (depending on how tolerant people
    are of your wishy-washy phrasing).


    Mike.


    They simply dogmatically state that the believe that I am wrong about
    this yet cannot point to the specific error because there is none:

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

    Then these steps would keep repeating:
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

    The above repeating pattern shows that the correctly simulated input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively proving that this simulated input never halts. This enables embedded_H
    to abort its simulation and correctly transition to Ĥ.qn.


    --
    Copyright 2021 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 All on Wed Mar 16 15:22:59 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/16/2022 3:11 PM, André G. Isaak wrote:
    On 2022-03-15 15:44, olcott wrote:
    On 3/15/2022 3:24 PM, André G. Isaak wrote:
    On 2022-03-15 08:51, olcott wrote:
    On 3/15/2022 6:35 AM, Malcolm McLean wrote:
    On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
    On 2022-03-14 21:07, olcott wrote:
    On 3/14/2022 9:05 PM, André G. Isaak wrote:
    On 2022-03-14 20:02, olcott wrote:

    <snip nonresponsive post>

    Again, I'll repeat the question which you dishonestly snipped
    rather
    than answering. I won't bother putting it in all caps or
    repeating it
    five times.

    How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be >>>>>>>> passed
    to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>>>>>

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

    The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect >>>>>>> reference
    away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass >>>>>>> this
    exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
    There are no 'levels of indirection' when discussing Turing Machines. >>>>>>
    If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an >>>>>> input
    to your decider, then your decider is broken since it must be able to >>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.

    Though that would actually be a genuine contribution to computer
    science.
    If you could devise a language such that a large subset of halting and >>>>> non-halting machines could be described, but not machines for which
    the
    halting status is difficult or impossible for a predefined halt
    decider to determine.

    André does not seem to be able to comprehend that a Turing machine
    decider cannot possibly have its own self or an encoding of its own
    self as its input. The closest thing possible that it can have is an
    encoding of another different instance of itself.

    Computations don't have different instances. What would it even mean
    to 'instantiate' a computation?

    André


    A Turing machine UTM that is simulating its own Turing machine
    description is two distinct instances: (executed and simulated) even
    if computer science does not bother to pay attention to this level of
    detail, or have the terminology to express it.

    You're confusing computations and Turing Machines.

    If you pass a UTM a description of itself, it will determine what UTM
    applied to an empty tape will do.

    UTM ⟨UTM⟩

    and

    UTM ∅

    are entirely distinct computations.

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

    In the above: Ĥ applied to ⟨Ĥ⟩ and the ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H
    vary by exactly one level of indirect reference.

    embedded_H does not, cannot, and its not supposed to report on the exact
    same computation that contains itself.

    embedded_H computes the mapping of its input ⟨Ĥ⟩ ⟨Ĥ⟩ a final state of embedded_H.

    They are not different 'instances'
    of some computation. Every "instance" of

    M ⟨I⟩

    is the exact same computation. So there is no point in talking about "instances".

    Do you actually understand what instantiation means?

    André


    What Does Instantiate Mean?
    Instantiate (a verb) and instantiation (the noun) in computer science
    refer to the creation of an object (or an “instance” of a given class)
    in an object-oriented programming (OOP) language. Referencing a class declaration, an instantiated object is named and created, in memory or
    on disk.

    https://www.techopedia.com/definition/26857/instantiate#:~:text=Instantiate%20(a%20verb)%20and%20instantiation,in%20memory%20or%20on%20disk.




    --
    Copyright 2021 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 All on Wed Mar 16 16:16:36 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/16/2022 3:58 PM, André G. Isaak wrote:
    On 2022-03-16 14:22, olcott wrote:
    On 3/16/2022 3:11 PM, André G. Isaak wrote:
    On 2022-03-15 15:44, olcott wrote:

    <snip>

    A Turing machine UTM that is simulating its own Turing machine
    description is two distinct instances: (executed and simulated) even
    if computer science does not bother to pay attention to this level
    of detail, or have the terminology to express it.

    You're confusing computations and Turing Machines.

    If you pass a UTM a description of itself, it will determine what UTM
    applied to an empty tape will do.

    UTM ⟨UTM⟩

    and

    UTM ∅

    are entirely distinct computations.

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

    In the above: Ĥ applied to ⟨Ĥ⟩ and the ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H
    vary by exactly one level of indirect reference.

    Which has absolutely nothing to do with my point since only *one* of the above is a computation; Ĥ applied to ⟨Ĥ⟩. The other, ⟨Ĥ⟩ ⟨Ĥ⟩ is a string
    which describes a computation, and the computation it describes is Ĥ
    applied to ⟨Ĥ⟩ which is the computation which your 'embedded_H' must answer about.


    You can dodge this fact a million times, none-the-less the copy of Linz
    H embedded at Ĥ.qx computes the mapping from its input to its own final
    state on the basis of the behavior of its correct simulation of this input.

    It is an easily verifiable fact that this simulated input would never
    reach its own final state in any finite number of steps of simulation.

    I will not address any other points until this point is fully addressed.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Wed Mar 16 20:34:24 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/16/2022 8:16 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/12/2022 8:55 PM, Ben Bacarisse wrote:
    André G. Isaak <agisaak@gm.invalid> writes:

    On 3/12/2022 5:57 PM, André G. Isaak wrote:

    So what string, according to you, encodes the computation Ĥ applied >>>>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate >>>>>> encodings as strings then they are not, in fact, different
    computations at all.

    No Comment?

    I know you've been asked this question before and have consistently
    ignored it. According to a recent post of yours that constitutes
    justification for a repetitive all-caps temper tantrum!
    I once tried to get a direct answer to this question. I asked 12 times
    in consecutive posts but never got one.
    Later, on the related question of whether ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
    computation I got this dazzling display of equivocation:
    "When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
    computation.
    When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES NOT encode a
    halting computation."
    Bear in mind that at time, PO's machines were magic: two identical state >>> transition functions could entail transitions to different states when
    presented with identical inputs. He has since backed off from some of
    these remarks, but it never exactly clear which previous claims he would >>> now accept were wrong.

    None-the-less...

    You mean you won't comment on the above but would rather present new
    junk about BASIC. Oh well... I can't stop you.


    It is true that the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its own final state in any finite steps of simulation by embedded_H.
    This means that it is an established fact that this inputs specifies a non-halting sequence of configurations.

    This means that the Linz proof that says:

    <Linz:1990:320>
    Now Ĥ is a Turing machine, so that it will have some description in Σ*,
    say ŵ . This string, in addition to being the description of Ĥ can also
    be used as input string. We can therefore legitimately ask what would
    happen if Ĥ is applied to ŵ .

    The contradiction tells us that our assumption of the existence of H,
    and hence the assumption of the decidability of the halting problem,
    must be false.
    </Linz:1990:320>

    is refuted because no contradiction is formed when Ĥ is applied to ⟨Ĥ⟩.

    Here is the full context:
    https://www.liarparadox.org/Linz_Proof.pdf

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Wed Mar 16 20:44:21 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/16/2022 8:30 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/12/2022 9:59 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    I've shown you how to write Linz's conditions in terms of simulation:
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
    Feel fee to replace "halts" with "would reach its final state" (and
    similarly for "does not halt") if it make you feel better. Both figures >>> of speech convey the same mathematical fact, but one is shorter and fits >>> on a line.
    What you can't do, if you want to keep talking about what Linz is
    talking about, is replace the reference to a UTM with embedded_H.

    Embedded_H has a full UTM as a part of it.

    Not in dispute.

    The Linz ⊢* wild card state transition allows for a UTM simulation to
    be a part of the decision process.

    Not in dispute.

    Embedded_H determines whether or not its simulated input would ever
    reach its final state if embedded_H remained in pure UTM mode.

    Not in dispute.

    It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the
    copy of H embedded within Ĥ would never reach the final state of this >>>> input ⟨Ĥ⟩.qn.
    Irrelevant. What matters is what follows logically from Linz's
    definition of a halt decider. If you think there is any point, I'll
    write it out again for you in terms of UTMs.

    If the input to embedded_H never halts and embedded_H correctly
    reports this that is most relevant.

    Not in dispute (except for the poor wording).

    If you want to know why you are still wrong after 14 years, you are
    going to have to learn to follow what other people are saying. Of
    course, if you did that, you'd see all your mistakes, so you are much
    better off remaining ignorant of what's being said to you.


    When the Linz H is embedded in the Linz Ĥ as a simulating halt decider
    then the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H presents infinitely nested simulation to embedded_H thus making the embedded_H transition to Ĥ.qn correct.

    This refutes the Linz proof because the Linz proof concludes that Ĥ
    applied to ⟨Ĥ⟩ results in a contradiction. (see direct quote below).

    </Linz:1990:320>
    Now Ĥ is a Turing machine, so that it will have some description in Σ*,
    say ŵ . This string, in addition to being the description of Ĥ can also
    be used as input string. We can therefore legitimately ask what would
    happen if Ĥ is applied to ŵ .

    The contradiction tells us that our assumption of the existence of H,
    and hence the assumption of the decidability of the halting problem,
    must be false.
    </Linz:1990:320>



    https://www.liarparadox.org/Linz_Proof.pdf

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Mar 18 12:37:17 2022
    XPost: comp.theory, sci.math, sci.logic

    On 3/18/2022 11:40 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/16/2022 8:30 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/12/2022 9:59 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    I've shown you how to write Linz's conditions in terms of simulation: >>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
    Feel fee to replace "halts" with "would reach its final state" (and
    similarly for "does not halt") if it make you feel better. Both figures >>>>> of speech convey the same mathematical fact, but one is shorter and fits >>>>> on a line.
    What you can't do, if you want to keep talking about what Linz is
    talking about, is replace the reference to a UTM with embedded_H.

    Embedded_H has a full UTM as a part of it.
    Not in dispute.

    The Linz ⊢* wild card state transition allows for a UTM simulation to >>>> be a part of the decision process.
    Not in dispute.

    Embedded_H determines whether or not its simulated input would ever
    reach its final state if embedded_H remained in pure UTM mode.
    Not in dispute.

    It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the
    copy of H embedded within Ĥ would never reach the final state of this >>>>>> input ⟨Ĥ⟩.qn.
    Irrelevant. What matters is what follows logically from Linz's
    definition of a halt decider. If you think there is any point, I'll >>>>> write it out again for you in terms of UTMs.

    If the input to embedded_H never halts and embedded_H correctly
    reports this that is most relevant.
    Not in dispute (except for the poor wording).
    If you want to know why you are still wrong after 14 years, you are
    going to have to learn to follow what other people are saying. Of
    course, if you did that, you'd see all your mistakes, so you are much
    better off remaining ignorant of what's being said to you.


    When the Linz H is embedded in the Linz Ĥ as a simulating halt decider
    then the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H presents infinitely nested >> simulation to embedded_H thus making the embedded_H transition to Ĥ.qn
    correct.

    No.


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

    Then these steps would keep repeating:
    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...

    (1) If embedded_H does not abort the simulation of its input the
    simulation never stops and the simulated input never reaches its final
    state.

    (2) If embedded_H does abort the simulation of its input the simulation
    is aborted at some point shown above and the simulated input never
    reaches its final state.

    This proves that ⟨Ĥ⟩ ⟨Ĥ⟩ presents embedded_H with a sequence of configurations that never reach a final state. This in turn makes the transition to Ĥ.qn by embedded_H correct.

    This refutes the Linz proof because the Linz proof concludes that Ĥ
    applied to ⟨Ĥ⟩ results in a contradiction. (see direct quote below).

    It refutes nothing.



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Mar 18 21:55:54 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/18/2022 11:40 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/16/2022 8:30 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/12/2022 9:59 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    I've shown you how to write Linz's conditions in terms of simulation: >>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
    Feel fee to replace "halts" with "would reach its final state" (and
    similarly for "does not halt") if it make you feel better. Both figures >>>>> of speech convey the same mathematical fact, but one is shorter and fits >>>>> on a line.
    What you can't do, if you want to keep talking about what Linz is
    talking about, is replace the reference to a UTM with embedded_H.

    Embedded_H has a full UTM as a part of it.
    Not in dispute.

    The Linz ⊢* wild card state transition allows for a UTM simulation to >>>> be a part of the decision process.
    Not in dispute.

    Embedded_H determines whether or not its simulated input would ever
    reach its final state if embedded_H remained in pure UTM mode.
    Not in dispute.

    It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the
    copy of H embedded within Ĥ would never reach the final state of this >>>>>> input ⟨Ĥ⟩.qn.
    Irrelevant. What matters is what follows logically from Linz's
    definition of a halt decider. If you think there is any point, I'll >>>>> write it out again for you in terms of UTMs.

    If the input to embedded_H never halts and embedded_H correctly
    reports this that is most relevant.
    Not in dispute (except for the poor wording).
    If you want to know why you are still wrong after 14 years, you are
    going to have to learn to follow what other people are saying. Of
    course, if you did that, you'd see all your mistakes, so you are much
    better off remaining ignorant of what's being said to you.


    When the Linz H is embedded in the Linz Ĥ as a simulating halt decider
    then the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H presents infinitely nested >> simulation to embedded_H thus making the embedded_H transition to Ĥ.qn
    correct.

    No.

    The reason that you only have a dogmatic reply rather than any
    supporting reasoning is that I am correct.

    No one can find any error in the following only because there is no
    error to be found.

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

    Then these steps would keep repeating:
    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...

    (1) If embedded_H does not abort the simulation of its input the
    simulation never stops and the simulated input never reaches its final
    state.

    (2) If embedded_H does abort the simulation of its input the simulation
    is aborted at some point shown above and the simulated input never
    reaches its final state.

    This proves that ⟨Ĥ⟩ ⟨Ĥ⟩ presents embedded_H with a sequence of configurations that never reach a final state. This in turn makes the transition to Ĥ.qn by embedded_H correct.

    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Sat Mar 19 08:34:57 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/19/2022 8:18 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/18/2022 11:40 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/16/2022 8:30 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 3/12/2022 9:59 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    I've shown you how to write Linz's conditions in terms of simulation: >>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
    Feel fee to replace "halts" with "would reach its final state" (and >>>>>>> similarly for "does not halt") if it make you feel better. Both figures
    of speech convey the same mathematical fact, but one is shorter and fits
    on a line.
    What you can't do, if you want to keep talking about what Linz is >>>>>>> talking about, is replace the reference to a UTM with embedded_H. >>>>>>
    Embedded_H has a full UTM as a part of it.
    Not in dispute.

    The Linz ⊢* wild card state transition allows for a UTM simulation to >>>>>> be a part of the decision process.
    Not in dispute.

    Embedded_H determines whether or not its simulated input would ever >>>>>> reach its final state if embedded_H remained in pure UTM mode.
    Not in dispute.

    It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the
    copy of H embedded within Ĥ would never reach the final state of this >>>>>>>> input ⟨Ĥ⟩.qn.
    Irrelevant. What matters is what follows logically from Linz's
    definition of a halt decider. If you think there is any point, I'll >>>>>>> write it out again for you in terms of UTMs.

    If the input to embedded_H never halts and embedded_H correctly
    reports this that is most relevant.
    Not in dispute (except for the poor wording).
    If you want to know why you are still wrong after 14 years, you are
    going to have to learn to follow what other people are saying. Of
    course, if you did that, you'd see all your mistakes, so you are much >>>>> better off remaining ignorant of what's being said to you.


    When the Linz H is embedded in the Linz Ĥ as a simulating halt decider >>>> then the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H presents infinitely nested >>>> simulation to embedded_H thus making the embedded_H transition to Ĥ.qn >>>> correct.
    No.

    The reason that you only have a dogmatic reply rather than any
    supporting reasoning is that I am correct.

    No, it's because there is no evidence that you can accept the
    explanations that are put to you.

    That is a bullshit excuse to hide the fact that you fail to understand
    what I said. You could provide an answer for posterity and for others
    that may eventually come to this post. The truth is you can't point out
    any specific error because there is no error.

    Do you really think it's worth my
    while explaining, yet again, that re-defining what H should do is just pointless?

    I'll take the time to explain if you ask intelligent questions, but my repeating that reply to what you keep cutting and pasting is just a
    waste of time.


    All of the "rebuttals" never pointing out any specific error and were
    always some kind of ad hominem attack of another.

    No one can find any error in the following only because there is no
    error to be found.


    No one can find any error in the following only because there is no
    error to be found.

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

    Then these steps would keep repeating:
    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...

    (1) If embedded_H does not abort the simulation of its input the
    simulation never stops and the simulated input never reaches its final
    state.

    (2) If embedded_H does abort the simulation of its input the simulation
    is aborted at some point shown above and the simulated input never
    reaches its final state.

    This proves that ⟨Ĥ⟩ ⟨Ĥ⟩ presents embedded_H with a sequence of configurations that never reach a final state. This in turn makes the transition to Ĥ.qn by embedded_H correct.

    You can't see the error. That's not the same thing at all.


    That no one pointed out a specific error is a verified fact.
    That no one pointed out an error because there is no error is a
    reasonably plausible conclusion.

    I some sense you clearly know that there is not halt decider because
    there would be no need to re-define what the correct answer is if you
    thought it were possible.


    Everyone (including Linz) makes the mistake that the copy of the Linz H embedded in Ĥ must report on its own behavior never realizing that this
    is just not the way that deciders work.

    It is an easily verified fact that simulating halt deciders (like all
    deciders) only compute the mapping from their inputs, thus are not even
    allowed to report on their own behavior.


    --
    Copyright 2021 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 Alan Mackenzie on Sat Mar 19 11:44:46 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/19/2022 11:22 AM, Alan Mackenzie wrote:
    olcott <NoOne@nowhere.com> wrote:
    On 3/19/2022 9:24 AM, Richard Damon wrote:
    On 3/19/22 10:13 AM, olcott wrote:

    [ .... ]

    Since itself is not an actual input to itself this does not form a
    contradictio

    Except that the input IS a 'copy' of itself, and thus must behave
    exactly like it. You don't seem to understand this property of Turing
    Machine. If you wish to dispute it, find an actual counter example.

    It can be empirically verified that the behavior of Ĥ applied to ⟨Ĥ⟩ is
    not the same as the behavior of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

    It can't be so verified without the code of H, which you refuse to
    publish, and which you certainly haven't written. (If you had, you'd be
    less bullish about its purported properties.)


    That we know that embedded_H is a simulating halt decider that aborts
    its simulation and rejects its input as soon as it detects an infinitely repeating behavior pattern tells us that rejecting its input would be
    correct on the basis of this infinitely repeating behavior pattern that
    we can see: (This by itself refutes Linz).


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

    Then these steps would keep repeating:
    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...

    There is no point in the above execution trace where the executing (not simulated) embedded_H can abort the simulation of its input where this simulated input reaches its own final state.

    When the original executing (not simulated) embedded_H sees the
    infinitely repeating pattern then it aborts its simulation killing every simulation in the whole process tree.

    The above repeating pattern shows that the correctly simulated input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn in asny finite number of steps conclusively proving that this simulated input never
    halts. This enables embedded_H to abort its simulation and correctly
    transition to Ĥ.qn.


    [ .... ]

    --
    Copyright 2021 Pete Olcott

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



    --
    Copyright 2021 Pete Olcott

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

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

    On 3/19/2022 12:29 PM, Richard Damon wrote:
    On 3/19/22 12:53 PM, olcott wrote:
    On 3/19/2022 11:33 AM, Richard Damon wrote:
    On 3/19/22 12:22 PM, Alan Mackenzie wrote:
    olcott <NoOne@nowhere.com> wrote:
    On 3/19/2022 9:24 AM, Richard Damon wrote:
    On 3/19/22 10:13 AM, olcott wrote:

    [ .... ]

    Since itself is not an actual input to itself this does not form a >>>>>>> contradictio

    Except that the input IS a 'copy' of itself, and thus must behave
    exactly like it. You don't seem to understand this property of Turing >>>>>> Machine. If you wish to dispute it, find an actual counter example.

    It can be empirically verified that the behavior of Ĥ applied to
    ⟨Ĥ⟩ is
    not the same as the behavior of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩. >>>>
    It can't be so verified without the code of H, which you refuse to
    publish, and which you certainly haven't written.  (If you had,
    you'd be
    less bullish about its purported properties.)

    [ .... ]


    Actually, what he is missing is that they are supposed to be the
    same, and as H/embedded_H needs to ALWAYS behave finitely, and go to
    Qn only if H^ applied to <H^> will never halt.

    No this is the moronic mistake of having a halt decider decide the
    halt status of a non-input non-finite string and no decider can ever
    do that.

    Deciders ONLY compute the mapping from their input finite strings to
    their own accept or reject state.


    Just shows who is the moron.

    The DEFINITION of a Halt Decider is that a Halt Decider applied to the
    string <M> w needs to report on the behavior of M applied to w.

    Every textbook has that incorrectly.
    A halt decider (because it is a decider) must report on the behavior
    specified by its finite string input.

    The behavior that is actually specified by this input is the actual
    behavior of this input when it is correctly simulated by its simulating
    halt decider.

    --
    Copyright 2021 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 Alan Mackenzie on Sat Mar 19 13:27:57 2022
    XPost: comp.theory, sci.logic, sci.math

    On 3/19/2022 1:18 PM, Alan Mackenzie wrote:
    olcott <NoOne@nowhere.com> wrote:
    On 3/19/2022 12:55 PM, Alan Mackenzie wrote:
    In comp.theory olcott <NoOne@nowhere.com> wrote:
    On 3/19/2022 11:22 AM, Alan Mackenzie wrote:
    olcott <NoOne@nowhere.com> wrote:

    [ .... ]

    It can be empirically verified that the behavior of Ĥ applied to ⟨Ĥ⟩ is
    not the same as the behavior of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

    It can't be so verified without the code of H, which you refuse to
    publish, and which you certainly haven't written. (If you had, you'd be >>>>> less bullish about its purported properties.)

    That we know that embedded_H is a simulating halt decider that aborts
    its simulation and rejects its input as soon as it detects an infinitely >>>> repeating behavior pattern tells us that rejecting its input would be
    correct on the basis of this infinitely repeating behavior pattern that >>>> we can see: (This by itself refutes Linz).

    That is not "empirical verification". "Empirical verification" would be >>> running H on a Turing Machine and checking whether or not it has the
    properties purported by you. We actually know, through mathematical
    reasoning, that it does not.

    Just as a matter of interest, your recent posts have been very
    repetitive. You are not saying anything new. You are also not saying
    anything correct. Now might be a very good time to cease posting on this >>> newsgroup, and devote your time and energies to something more
    life-enhancing.

    Like everyone else, I prove my point, ....

    You fail to prove your point. What you call your "proofs" are not
    logically sound.

    .... you erase the part that proved my point and then claim that I did
    not prove my point.

    Richard and Ben (and one or two others) have pointed out the deficiencies
    in what you call your proof, and done so very many times. You reply with abuse and insults, to a large extent. I've no desire to become a
    recipient of such abuse.
    No one can possibly point out an error in these three points:

    (1) A halt decider (because it is a decider) must report on the behavior specified by its finite string input.

    (2) The behavior that is actually specified by this input is the actual behavior of this input when it is correctly simulated by its simulating
    halt decider (which contains a full UTM).

    (3) If a simulating halt decider (SHD) aborts its simulation only
    because it correctly detected that its simulation would never stop
    unless it was aborted then the SHD is necessarily correct when its
    rejects this input.

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