• Re: Concise refutation of halting problem proofs V19

    From olcott@21:1/5 to Richard Damon on Fri Nov 19 21:14:17 2021
    XPost: comp.theory, sci.logic, sci.math

    On 11/19/2021 8:27 PM, Richard Damon wrote:
    On 11/19/21 3:03 PM, olcott wrote:
    typedef int (*ptr)();

    int H(ptr x, ptr y)
    {
       x(y);  // direct execution of P(P)
       return 1;
    }

    // Minimal essence of Linz(1990) Ĥ
    // and Strachey(1965) P
    int P(ptr x)
    {
       H(x, x);
       return 1;  // Give P a last instruction at the "c" level
    }

    int main(void)
    {
       H(P, P);
    }

    computation that halts
    a computation is said to halt whenever it enters a final state.
    (Linz:1990:234)

    PSR set:
    Combinations of H/P having pathological self-reference
    For every possible H of H(P,P) invoked from main() where P(P) calls
    this same H(P,P) and H simulates or executes its input and aborts or
    does not abort its input P never reaches its last instruction.

    PSR subset:
    Because we know that the input to H(P,P) never halts for the whole PSR
    set and a subset of these H/P combinations aborts the execution or
    simulation of its input then we know that for this entire subset the
    input to H(P,P) never halts and P(P) halts.

    This conclusively proves when the input to H(P,P) never halts and the
    same P(P) does halt that this does not form a contradiction.


    ??? Since the input to H(P,P) IS P(P) it can't do both.

    You seem to mean that if the partial simulation done by H while
    processing H(P,P) never reaches its halting state is not a contradiction
    to the execution of P(P) reaching such a halting state.

    That is true, but since the definition of the right answer to the
    halting problem is the latter, claiming the the partial simulation gives
    the right answer isn't a contradiction, it is just a out and out LIE and
    a FALSEHOOD.

    Fundamentally, you just don't understand what this 'input' stuff means.

    FAIL you liar.


    I have finally specified my point precisely and clearly enough that any competent software engineer can totally understand what I am saying even
    with no knowledge of computer science or the halting problem.

    On this basis I have totally proved that I know what "input" is in that
    the above H(P,P) does directly invoke P(P).



    Halting problem undecidability and infinitely nested simulation (V2)
    November 2021 PL Olcott

    https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2






    --
    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 Fri Nov 19 22:20:06 2021
    XPost: comp.theory, sci.logic, sci.math

    On 11/19/2021 9:43 PM, Richard Damon wrote:
    On 11/19/21 10:14 PM, olcott wrote:
    On 11/19/2021 8:27 PM, Richard Damon wrote:
    On 11/19/21 3:03 PM, olcott wrote:
    typedef int (*ptr)();

    int H(ptr x, ptr y)
    {
       x(y);  // direct execution of P(P)
       return 1;
    }

    // Minimal essence of Linz(1990) Ĥ
    // and Strachey(1965) P
    int P(ptr x)
    {
       H(x, x);
       return 1;  // Give P a last instruction at the "c" level
    }

    int main(void)
    {
       H(P, P);
    }

    computation that halts
    a computation is said to halt whenever it enters a final state.
    (Linz:1990:234)

    PSR set:
    Combinations of H/P having pathological self-reference
    For every possible H of H(P,P) invoked from main() where P(P) calls
    this same H(P,P) and H simulates or executes its input and aborts or
    does not abort its input P never reaches its last instruction.

    PSR subset:
    Because we know that the input to H(P,P) never halts for the whole
    PSR set and a subset of these H/P combinations aborts the execution
    or simulation of its input then we know that for this entire subset
    the input to H(P,P) never halts and P(P) halts.

    This conclusively proves when the input to H(P,P) never halts and
    the same P(P) does halt that this does not form a contradiction.


    ??? Since the input to H(P,P) IS P(P) it can't do both.

    You seem to mean that if the partial simulation done by H while
    processing H(P,P) never reaches its halting state is not a
    contradiction to the execution of P(P) reaching such a halting state.

    That is true, but since the definition of the right answer to the
    halting problem is the latter, claiming the the partial simulation
    gives the right answer isn't a contradiction, it is just a out and
    out LIE and a FALSEHOOD.

    Fundamentally, you just don't understand what this 'input' stuff means.

    FAIL you liar.


    I have finally specified my point precisely and clearly enough that
    any competent software engineer can totally understand what I am
    saying even
    with no knowledge of computer science or the halting problem.

    On this basis I have totally proved that I know what "input" is in that
    the above H(P,P) does directly invoke P(P).

    So, I guess you are lying about working on the Halting Problem of
    Computation theory and that your results apply to it.

    The 'Input' to a Halt Decider MUST BE a description of the Computation
    that the decider is to answer about.

    Actually this is incorrect in the case where the input to the halt
    decider specifies a [sequence of configurations] that never halts.

    computation
    The sequence of configurations leading to a halt state will be called a computation. (Linz:1990:238)

    In the case of the x86 language we could provide the assembly language
    source code as the "description" of a [sequence of configurations] or we
    could simply provide the actual x86 machine code. Thus this description
    is also directly executable.

    In any case the input to H is shown to be directly executed and any
    competent software engineer like you can tell that this same input could
    also be simulated by an x86 emulator.



    Halting problem undecidability and infinitely nested simulation (V2)
    November 2021 PL Olcott

    https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2









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