• That P(P) of main() halts does not contradict H(P,P)==0 [ ignorance

    From olcott@21:1/5 to Ben Bacarisse on Thu Sep 2 10:23:14 2021
    XPost: comp.theory, comp.software-eng, sci.logic

    On 9/2/2021 6:28 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

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

    On 9/1/2021 7:58 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 9/1/2021 9:44 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ never halts [UNLESS] it aborts its simulation,
    not very hard at all for people that care about truth as opposed to >>>>>>>> and contrast with winning an argument.

    (correction added from your own follow-up)
    Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ halts. It halts in rejecting state Ĥ.qn. There
    is no dispute about this fact from you or anyone else. The /reason/ it >>>>>>> halts is interesting to you, but /not/ to anyone else.

    The facts remain: ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation and you were
    flat-out wrong to say that is does not. And H (the machine embedded in >>>>>>> Ĥ at Ĥ.qx) is wrong to reject the string for that reason. You will >>>>>>> never admit either mistake.
    That you are wrong is so blinding obvious that any paper you write about
    the theorem will go in the editor's bin in seconds. (Unless he or she >>>>>>> decides it's worth pinning on the staff room notice board for fun.) >>>>>>
    The reason that I created the x86utm operating system was to enable >>>>>> every single detail of the halting problem to be specified at the high >>>>>> level of abstraction of C/x86 so that people don't merely imagine
    details that are not true.

    You created it to distract from the massive lies you told in Dec 2018: >>>>>
    "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."
    "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz >>>>> specs does not exist. I now have a fully encoded pair of Turing >>>>> Machines H / Ĥ proving them wrong."

    You need to concentrate the steaming pile of x86 code you are hiding >>>>> rather than on the TM you lied about having. And try to avoid saying >>>>> anything clearly, because every time you do you get burned. Your ⟨Ĥ⟩
    ⟨Ĥ⟩ encodes a halting computation and your H should accept it.

    In other words x86 code is beyond your technical competence.
    Nothing wrong with that except hiding it behind denigration.

    The reasons why you are wrong are clearly laid out.

    This is the key element and although it is self-evidently true it
    really could use a much better proof.

    PREMISE ONE
    Simulating Halt Decider Theorem (Olcott 2020):
    A simulating halt decider correctly decides that any input that never
    halts unless the simulating halt decider aborts its simulation of this
    input is an input that never halts.

    Does this support the fact that your ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation, and that your H should accept it? If so, just say "sorry,
    I was wrong". If it does /not/ support that fact, then you need to find
    out what is wrong with it.


    This might actually be legitimately beyond your capacity to understand:

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

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

    Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
    if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and

    Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
    if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

    This criteria merely relies on the fact that the UTM simulation of a
    machine description of a machine is computationally equivalent to the
    direct execution of this same machine:

    Simulating Halt Decider Theorem (Olcott 2020):
    A simulating halt decider correctly decides that any input that never
    halts unless the simulating halt decider aborts its simulation of this
    input is an input that never halts.

    (A) The first line of main() halts.
    This is analogous to the first element of Ĥ halts.

    (B) The input to the first line of P never halts.
    This is analogous to the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.

    That you insist that we only pay attention to (A) and can safely ignore
    (B) might legitimately be simply ignorance on your part.




    We have been around and around about this and none of the dishonest
    dodges cracked the logical necessity at all.

    ...but you keep dodging none the less. You are wrong for very simple reasons. So simple that you must post waffle like the above rather than address them. You hope the waffle will draw the fire away from the fact
    that your string pair ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation and your H
    should accept it.

    The string pair <M> w is /defined/ as the encoding of the computation
    M(w) (that's M with w on the tape) and you know that Ĥ(⟨Ĥ⟩) halts and that H should not reject string pairs that encode halting computations.
    Can I put it any more simply than this? Will you address this error?
    No. You will post more stuff in the hope of getting people to talk
    about anything but the core mistake.



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Thu Sep 2 20:42:21 2021
    XPost: comp.theory, comp.software-eng, sci.logic

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

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

    On 9/2/2021 7:27 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    Anyone that understands what I am saying can tell that their have been >>>>>> zero actual rebuttals.

    Is that an empty set? Does anyone in the world understand and agree >>>>> with you? Someone at the grocery store maybe?
    Well? Does anyone in the world understand and agree with you? Will you >>> avoid every question put to you?

    None of the rebuttals ever directly addressed any of the points that I >>>> made. They always changed the subject to another different unrelated
    point.
    Flat-out lie. You made this point crucial point on 12th Aug:
    "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation." >>
    Ĥ.q0 ⟨Ĥ1⟩ // You pay attention to this
    Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // You utterly ignore this

    Liar. I have addressed this on many occasions. Here, yet again, is
    what I have to say about it. You show us that Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊦ Ĥ.qn and
    since ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ we see that H (embedded as it is at Ĥ.qx)
    rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩. How you think I knew that? I don't make
    this stuff up, you do.


    The simple fact that you ignore is that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts unless Ĥ.qx aborts its simulation of this input.
    You have dodged this 2017-03-11 (4.5 years ago)

    On 3/11/2017 3:13 PM, peteolcott wrote:
    http://LiarParadox.org/HP_Infinite_Recursion.pdf

    As this page 319 of An Introduction to Formal Languages and Automata
    by Peter Linz 1990 indicates

    From H' we construct another Turing machine H-Hat. This new machine
    takes as input Wm, copies it then behaves exactly like H'.

    q0 Wm |-* H-Hat q0 Wm Wm...

    Page 320 indicates that we apply H-Hat to itself as input.

    The problem is that every H-Hat needs a pair of inputs.

    H-Hat takes an H-Hat as input and copies it so that it
    can analyze how its input H-hat would analyze the copy
    of H-Hat that it just made.

    The input H-Hat would have to copy its own input H-Hat
    so that it can analyze what its own input H-Hat would
    do on its own input, on and on forever...

    Copyright 2016 and 2017 Pete Olcott.



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Malcolm McLean on Fri Sep 3 08:51:47 2021
    XPost: comp.theory, comp.lang.prolog, sci.math

    On 9/3/2021 6:47 AM, Malcolm McLean wrote:
    On Friday, 3 September 2021 at 11:32:41 UTC+1, richar...@gmail.com wrote:
    On 9/3/21 12:09 AM, olcott wrote:
    On 9/2/2021 10:52 PM, Richard Damon wrote:
    On 9/2/21 11:18 PM, olcott wrote:
    On 9/2/2021 10:09 PM, Richard Damon wrote:
    On 9/2/21 10:55 PM, olcott wrote:
    On 9/2/2021 9:42 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 9/2/2021 8:29 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 9/2/2021 8:05 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 9/2/2021 7:27 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    Anyone that understands what I am saying can tell that their >>>>>>>>>>>>>>> have been
    zero actual rebuttals.

    Is that an empty set? Does anyone in the world understand and >>>>>>>>>>>>>> agree
    with you? Someone at the grocery store maybe?
    Well? Does anyone in the world understand and agree with you? >>>>>>>>>>>> Will you
    avoid every question put to you?

    None of the rebuttals ever directly addressed any of the points >>>>>>>>>>>>> that I
    made. They always changed the subject to another different >>>>>>>>>>>>> unrelated
    point.
    Flat-out lie. You made this point crucial point on 12th Aug: >>>>>>>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting >>>>>>>>>>>> computation."

    Ĥ.q0 ⟨Ĥ1⟩ // You pay attention to this
    Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // You utterly ignore this

    Liar. I have addressed this on many occasions. Here, yet
    again, is
    what I have to say about it. You show us that Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊦
    Ĥ.qn
    and
    since ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ we see that H (embedded as it is at Ĥ.qx)
    rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩. How you think I knew that? I don't
    make
    this stuff up, you do.

    The simple fact that you ignore is that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩
    never halts unless Ĥ.qx aborts its simulation of this input. >>>>>>>>> You have dodged this EVER SINCE 2017-03-11 (4.5 years ago)

    Liar. Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ transitions to Ĥ.qn.

    The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.

    When I say that I have a brown dog is it not a
    rebuttal to say that I don't have a white cat.

    The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
    The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
    The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
    The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.

    You have been dishonestly denying this for 4.5 years.
    You have been dishonestly denying this for 4.5 years.
    You have been dishonestly denying this for 4.5 years.
    You have been dishonestly denying this for 4.5 years.


    INPUTS DON'T HALT,


    Any input that never halts unless its simulation is aborted is an input >>>>> that never halts.


    Bad Terminology. Inputs themselves don't halt. They only represent
    computations that might be halting or not.


    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
    Right. Note, it says whether 'The Program' not 'The Input' will halt or
    not.

    Programs will Halt, not inputs. Inputs are just the desciption used to
    specify the program.

    There seems to be some sort of claim that whilest H_Hat<H_Hat> is
    halting, the string pair <H_Hat><H_Hat> (angle brackets represent tape contents) is non-halting. I really can't get to the bottom of what exactly is being claimed here.

    The H(P,P) C/x86 code makes a perfect and complete analogy to the
    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ Turing machine code. If you don't understand the x86 language well enough you won't be able to ever understand what I am saying.

    All of the actual Turing Machine base proofs must leave out almost all
    of the details because their programs would hundreds of thousands of
    pages. A TM with random access memory would be far less of a nightmare
    to deal with.


    To bypass the pathology of pathological inputs:
    FAIL. You don't get to change the definition because you don't like the
    problems it creates.

    You can't "solve the halting problem". You can maybe propose a set which has some relationship to the halting / non-halting sets of Turing machines, and has interesting properties. That's not really a FAIL, unless you set yourself the
    insane goal of "solving the halting problem".
    Trying to define a set of "pathological inputs" isn't an example of something which is original, however,, and it's well known to be a dead end.

    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

    To bypass the pathology of pathological inputs:
    In computability theory, the halting problem is the
    problem of determining, from a description of an arbitrary
    computer program and an input,

    whether the simulation of this program must be aborted to
    prevent it from running forever.

    The above criteria is valid on the basis of the known equivalence
    between the direct execution of a computation and its simulation
    by a UTM. The same criteria universally works on all inputs allowing
    their halting status to be correctly decided.




    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Fri Sep 3 09:05:20 2021
    XPost: comp.theory, comp.software-eng, sci.math

    On 9/2/2021 11:59 PM, André G. Isaak wrote:
    On 2021-09-02 22:09, olcott wrote:
    On 9/2/2021 10:52 PM, Richard Damon wrote:
    On 9/2/21 11:18 PM, olcott wrote:

    Any input that never halts unless its simulation is aborted is an input >>>> that never halts.


    Bad Terminology. Inputs themselves don't halt. They only represent
    computations that might be halting or not.


        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

    To bypass the pathology of pathological inputs:
        In computability theory, the halting problem is the
        problem of determining, from a description of an arbitrary
        computer program and an input,

        whether the simulation of this input must be aborted to
        prevent it from running forever.

    The above criteria is valid on the basis of the known equivalence
    between the direct execution of a computation and its simulation by a
    UTM. The same criteria universally works on all inputs.

    But the direct execution of P(P) *does* halt. So if there is an
    equivalence between direct execution and simulation by a UTM, then the simulation by a UTM must also halt.

    André


    The direct execution of P has a dependency on the H(P,P) that it calls.
    int main(){ P(P); } only halts because its call to H(P,P) returns 0. No instance of H(P,P) has any dependency on the return value of another
    function.

    This makes int main(){ P(P); } a computationally distinct different
    computation than H(P,P) that has no such dependency.

    You can dance all around this yet there exists no correct rebuttal in
    the universe that shows that these computations are equivalent or that computations that are not equivalent must have equivalent behavior.



    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

    To bypass the pathology of pathological inputs:
    In computability theory, the halting problem is the
    problem of determining, from a description of an arbitrary
    computer program and an input,

    whether the simulation of this program must be aborted to
    prevent it from running forever.

    The above criteria is valid on the basis of the known equivalence
    between the direct execution of a computation and its simulation
    by a UTM. The same criteria universally works on all inputs allowing
    their halting status to be correctly decided.



    --
    Copyright 2021 Pete Olcott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Ben Bacarisse on Fri Sep 3 09:20:23 2021
    XPost: comp.theory, comp.software-eng, sci.math

    On 9/3/2021 8:41 AM, Ben Bacarisse wrote:
    Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

    Programs will Halt, not inputs. Inputs are just the desciption used to
    specify the program.

    There seems to be some sort of claim that whilest H_Hat<H_Hat> is
    halting, the string pair <H_Hat><H_Hat> (angle brackets represent tape
    contents) is non-halting. I really can't get to the bottom of what exactly is
    being claimed here.

    I think that's deliberate, now. Several people have tried to get him to
    use terms correctly (or, as a last resort, invent new well-defined
    ones), but he won't do that because the obfuscation is all he has left.


    Ĥ.q0 ⟨Ĥ1⟩ // is equivalent to int main() { P(P); }
    Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // is equivalent to H(P,P)

    The H(P,P) C/x86 code makes a perfect and complete analogy to the
    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ Turing machine code. If you don't understand the x86 language well enough you won't be able to ever understand what I am saying.

    All of the actual Turing Machine base proofs must leave out almost all
    of the details because their programs would hundreds of thousands of
    pages. A TM with random access memory would be far less of a nightmare
    to deal with.

    It is obvious that every simulation of P(P) would never halt unless H
    aborts its simulation of P(P) to everyone one sufficiently understanding
    the material.

    It is obvious to everyone one sufficiently understanding the material
    that all "rebuttals" are based on either deception or failing to
    understand the material.

    I show that X is true because of Y and the "rebuttal" essentially takes
    the form: "I just don't believe that".

    He has said

    "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation" (Aug
    2021)

    This is as wrong as saying "2 plus 2 is not 4" but when it's pointed out
    that ⟨Ĥ⟩ ⟨Ĥ⟩ /does/ encode a halting computation he says

    "the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts" (Aug 2021)

    which is akin to responding to the fact that 2+2=4 with "the input to 2a
    plus 2b goes not four".

    The bad wording is seems suspiciously deliberate. What else has he got?
    He hopes, I think, that people will argue about the bad wording and not challenge the basic error.

    ... unless you set yourself the insane goal of "solving the halting
    problem".

    PO has claimed, in a court of law, to be God. I think we can safely say
    that his relationship with reality is... er... fragile.



    --
    Copyright 2021 Pete Olcott

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

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