• DD simulated by HHH cannot reach its own final state state

    From olcott@polcott333@gmail.com to comp.theory,comp.lang.c,comp.lang.c++,comp.ai.philosophy on Thu Dec 18 02:02:54 2025
    From Newsgroup: comp.ai.philosophy

    On 9/19/2025 8:22 PM, vallor wrote:
    On Fri, 19 Sep 2025 10:02:58 -0500, olcott <polcott333@gmail.com> wrote in <10ajrb4$ik2f$1@dont-email.me>:

    On 9/19/2025 5:31 AM, vallor wrote:
    On Fri, 19 Sep 2025 10:49:15 +0200, "Fred. Zwarts" <F.Zwarts@HetNet.nl>
    wrote in <10aj5ea$cf6i$5@dont-email.me>:

    Op 19.sep.2025 om 03:51 schreef olcott:
    On 9/18/2025 8:38 PM, Kaz Kylheku wrote:
    The pattern that you outlined is exactly the same as the recursion
    depth of mutual recursion.

    It is easy to cheat and come to some other fake conclusion. No other >>>>> correct conclusion exists.

    The failure of a simulator to reach the final halt state is not a
    proof for non-termination behaviour.

    In particular when other simulators have proven that the exact same
    input specifies a program for which the final halt state can be
    reached.
    That is true for the HHH that aborts after two cycles of recursion.
    What we see is that 1) If HHH does not abort, it does not provide any
    answer,
    so it fails. 2) If HHH does abort, it aborts prematurely, because the
    input has changed. A correct simulation would reach the final halt
    state one cycle later. It is incorrect for HHH to report on another
    hypothetical input with a different finite string that include the HHH >>>> that does not abort.
    It mus abort on the input that includes the HHH that aborts.

    You confuse your self by not clearly separating the input and the code >>>> of the decider. But a TM cannot report about another TM, so the full
    program, DDD including all functions called by it directly or
    indirectly, in particular including the HHH called by DDD, must be
    part of the input.

    By George, I think this is the crux of Olcott's confusion. I know you
    all understand this, but I don't think Peter does:

    Ignoring for a second that the "machine string" he's passing to HHH()
    is a pointer, consider the string to which the pointer points: it is a
    function that includes a call to HHH(). So a good chunk of HHH() is
    part of the input string, including the parts that cause the actual
    paradox: DD() halts, because it has "decided" (incorrectly) that it
    doesn't halt. But it does, because it includes the code from HHH.

    Peter, If you run DD() by itself, it halts -- and let's not hear
    anymore of this talk about HHH() and DD() being none of each other's
    business, because the code for DD() includes the code for HHH(),
    standalone or otherwise.


    When we make HHH an integral part of the operating system that checks
    every function called from main() then yet again main-->DD() is rejected
    as non-halting.
    main-->DD() has always specified the equivalent of infinite recursion.

    But DD() includes the specification of HHH(DD) (by reference) -- ignoring
    the results of HHH(DD) isn't allowed.

    Consider the call to HHH() if it were inlined. You have a considerable
    chunk of your halt decider guts as part of the DD input string. You
    can't ignore that and hand-wave it away -- and that is the crux of the matter: you continue to ignore a very large chunk of the input string.

    When HHH sees it right away it says it right away. When HHH does not see
    it until the second recursive call then it makes it looks like
    main-->DD() halted on its own without intervention.

    It did halt on its own, because DD() calls HHH(), which points to a considerable amount of code that you seem to be hand-waving away.

    Everyone here knows that intervention was required or main-->DD() would
    have never halted yet ignore this so that they can remain in
    disagreement mode.

    Actually, everyone can see (even me) that that-which-is-referred-to-by
    HHH is part of the input string DD. You can't ignore that.

    What I did figure out (by putting myself in your shoes) is that you apparently don't consider that-which-is-referred-to by HHH as part
    of (that-which-is-referred-to-by) DD.

    Crudely, the input string DD contains the contents of HHH. You
    can't ignore that.


    int P()
    {
    int Halt_Status = H(P);
    if (Halt_Status)
    HERE: goto HERE;
    return Halt_Status;
    }

    int main()
    {
    H(P);
    return 0;
    }

    While DD is simulated by HHH according to the
    semantics of the C programing language the
    simulated DD cannot possibly reach its own
    simulated "return" statement final halt state.
    --
    Copyright 2025 Olcott<br><br>

    My 28 year goal has been to make <br>
    "true on the basis of meaning expressed in language"<br>
    reliably computable.<br><br>

    This required establishing a new foundation<br>
    --- Synchronet 3.21a-Linux NewsLink 1.2