• Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ onl

    From olcott@21:1/5 to Mike Terry on Thu Apr 7 12:43:51 2022
    XPost: comp.theory, sci.math, sci.logic

    On 4/7/2022 12:31 PM, Mike Terry wrote:
    On 07/04/2022 01:24, Dennis Bush wrote:
    On Wednesday, April 6, 2022 at 8:20:16 PM UTC-4, olcott wrote:
    On 4/6/2022 7:17 PM, Dennis Bush wrote:
    On Wednesday, April 6, 2022 at 8:10:14 PM UTC-4, olcott wrote:
    On 4/6/2022 6:44 PM, Ben Bacarisse wrote:
    olcott <No...@NoWhere.com> writes:

    On 4/6/2022 6:27 PM, Ben Bacarisse wrote:

    ... Your hobby seems to be posting here. Are you having fun
    posting here?

    I am enjoying posting here because progress continues to occur.

    That's fine. I'd like to think I am helping to entertain you.

    I have
    my whole proof boiled down to the correct understanding of a single >>>>>>> (very difficult to understand) sentence.

    Except for the two questions you can't answer without it all
    unravelling!

    You merely continue to greatly disrespectfully refuse to pay enough
    attention:

    It is the case that the correctly simulated input to embedded_H can
    never possibly reach its own final state under any condition at all. >>>>> Therefore embedded_H is necessarily correct to reject its input.

    But how can we verify that the input was correctly simulated?
    The exection trace that is specified by its TM description.

    But another halt decider simulates the same input to completion.  So
    the claim that the input "can never possibly reach its own final state
    under any condition at all" is false:

    Given an embedded_H that aborts its simulation which we'll call
    embedded_Ha, is embedded_Ha (and therefore Ha) correct to reject
    <Ha^><Ha^>?

    Now we have Hb, which has the exact same halting criteria as Ha except
    it defers aborting for k steps. Hb simulates <Ha^><Ha^> and is able to
    reach the input's final state of <Ha^.qn> while remaining in UTM mode
    and accepts this input. This tells us that embedded_Ha is not correct
    to reject <Ha^><Ha^> because it aborted too soon.


    PO really really really really really believes that when his simulator observes his "infinite recursive behaviour" pattern, that really really really really means that the simulation is exhibiting infinite recursive behaviour, and so would never halt however far it is continued.

    It does not matter to PO that he has actually run the computation
    outside of the simulator, and observed himself that the computation is halting!!!!!!

    If you are a guard assigned to watch the front door any nothing comes in
    the front door then you are correct to report that nothing has come in
    the front door no matter what comes in anywhere else.

    The actual behavior of the actual input to embedded_H is the front door.

    The actual behavior of any damn thing else anywhere else IS NOT THE
    FRONT DOOR.

    embedded_H computes the mapping from its inputs
    from its inputs
    from its inputs
    from its inputs
    from its inputs
    from its inputs not any damn other place else.

    --
    Copyright 2022 Pete Olcott

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

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