• Re: Concise refutation of halting problem proofs V27 [ finally mathemat

    From olcott@21:1/5 to All on Mon Nov 22 21:59:13 2021
    XPost: comp.theory, sci.logic, sci.math

    On 11/22/2021 7:44 PM, André G. Isaak wrote:
    On 2021-11-22 18:16, olcott wrote:
    On 11/22/2021 7:07 PM, André G. Isaak wrote:
    On 2021-11-22 17:13, olcott wrote:
    On 11/22/2021 5:16 PM, André G. Isaak wrote:

    And this bit is particularly mystifying:

    PSR_set: for n = 0 to ∞
    {
    ;    (Input_Never_Halts(  Hn(Pn,Pn)  ))
    ;    (Sometimes_Halts(  Hn(Pn,Pn)  ))
    ;    (Sometimes_Halts(   Pn(Pn)  ))
    }

    André



    Numbered elements of the infinite set of finite string C encodings
    of H and P. The source-code that I provided is the (H0, P0) element.

    That wasn't the mystifying part despite it being a strange abuse of
    syntax. I assumed this was just a deranged way of writing ∀n rather
    than being a syntactically ill-formed C program, though why you
    continuously insist on inventing your own undefined notation is
    beyond me.

    How can the input of Hn(Pn, Pn) never halt when Pn(Pn) sometimes halt?

    The input to Hn(Pn,Pn) never reaches its final state.
    For some of these exact same Pn(Pn) P does reach its final state.

    Which goes back to Richard's question which you refused to answer: What
    does Input_Never_Halts mean?

    The input to a halt decider is a *string*. The input can't halt. It also can't not halt. Only the computation which it describes has a halting
    status, and in the case of Hn(Pn, Pn) the input describes the
    computation Pn(Pn).

    You keep talking about what the 'input' does, but unless by 'input' you
    mean 'the computation described by the input' this is a completely
    undefined and, as far as I can tell, meaningless notion. Halting is a property of *computations*, not of strings.

    So what does Input_Never_Halts mean?

    What does it mean for an input to halt or not halt?


    It turns out that the independent execution of P(P) actually means an
    input to H(P,P) that *is not* an input to H(P,P).

    It turns out that the independent execution of P(P) means that main()
    directly executes P(P) without H being involved.

    No deciders can actually work that way. All deciders either accept or
    reject finite string inputs.

    H is a computable function that accepts or rejects inputs in its domain
    on the basis that these inputs specify a sequence of configurations that
    reach their final state.

    What all you guys have been asking for is for H to have an input that
    *is not* its input.

    The x86 equivalent of a TM description and its input is an x86 machine
    language string and some other finite string or references to these.



    And if Hn is a halt decider, how can it only sometimes halt?


    I am using categorically exhaustive reasoning examining the behavior
    of every possible Hn(Pn,Pn) by examining the categories of possible
    behavior.

    Only a subset of Hn(Pn,Pn) is H a decider and in only a subset of
    these is H a correct halt decider.

    And what does it even mean for something to sometimes halt? For any
    given value of n it either halts or it doesn't.

    Not going to answer this, I take it?

    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)