• Re: Mike can't even count to eight --- HHH(DDD)

    From Mike Terry@21:1/5 to olcott on Tue Jun 10 17:42:53 2025
    On 10/06/2025 17:17, olcott wrote:
    On 6/10/2025 11:09 AM, Mike Terry wrote:
    On 10/06/2025 12:41, Mikko wrote:
    On 2025-06-10 00:47:12 +0000, olcott said:

    On 6/9/2025 7:26 PM, Richard Damon wrote:
    On 6/9/25 10:43 AM, olcott wrote:
    On 6/9/2025 5:31 AM, Fred. Zwarts wrote:
    Op 09.jun.2025 om 06:15 schreef olcott:
    On 6/8/2025 10:42 PM, dbush wrote:
    On 6/8/2025 11:39 PM, olcott wrote:
    On 6/8/2025 10:32 PM, dbush wrote:
    On 6/8/2025 11:16 PM, olcott wrote:
    On 6/8/2025 10:08 PM, dbush wrote:
    On 6/8/2025 10:50 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>
    No it's not, as halt deciders / termination analyzers work with algorithms,

    That is stupidly counter-factual.


    That you think that shows that

    My understanding is deeper than yours.
    No decider ever takes any algorithm as its input.

    But they take a description/specification of an algorithm,

    There you go.

    which is what is meant in this context.

    It turns out that this detail makes a big difference.

    And because your HHH does not work with the description/ specification of an algorithm, by
    your own admission, you're not working on the halting problem. >>>>>>>>>

    HHH(DDD) takes a finite string of x86 instructions
    that specify that HHH simulates itself simulating DDD.

    And HHH fails to see the specification of the x86 instructions. It aborts before it can see
    how the program ends.


    This is merely a lack of sufficient technical competence
    on your part. It is a verified fact that unless the outer
    HHH aborts its simulation of DDD that DDD simulated by HHH
    the directly executed DDD() and the directly executed HHH()
    would never stop running. That you cannot directly see this
    is merely your own lack of sufficient technical competence.

    And it is a verified fact that you just ignore that if HHH does in fact abort its simulation of
    DDD and return 0, then the behavior of the input, PER THE ACTUAL DEFINITIONS, is to Halt, and
    thus HHH is just incorrect.


    void DDD()
    {
       HHH(DDD);
       return;
    }

    How the f-ck does DDD correctly simulated by HHH
    reach its own "return" statement final halt state?

    If HHH is not a decider the question is not interesting.
    If HHH is a deider it returns. The first insturunction
    after the return terminates the execution of DDD.

    But then DDD *simulated by HHH* does is not simulated as far as its own return statement.  In fact
    zero steps of DDD are simulated.


    Since I have shown you the execution trace of DDD simulated
    by HHH many times it is gross negligence that you say that
    "zero steps of DDD are simulated."

    Upon closer inspection it seems I misread what Mikko was saying. I misread that he was suggesting
    an HHH which returned straight away. So just ignore my "zero steps" remark.

    My other remarks look right:

    - But then DDD *simulated by HHH* is not simulated as far as its own return statement.
    HINT: I'm agreeing with you.
    HINT: Mikko, Fred and Richard have all also agreed with that statement,
    Nobody has agreed that that implies that DDD halts. <=== THAT is your disagreement.
    You're welcome.
    - Of course, DDD directly executed will reach its own return statement,
    so it is true that this DDD halts...


    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Mike Terry on Tue Jun 10 19:22:39 2025
    On 10/06/2025 17:42, Mike Terry wrote:
    On 10/06/2025 17:17, olcott wrote:
    On 6/10/2025 11:09 AM, Mike Terry wrote:
    On 10/06/2025 12:41, Mikko wrote:
    On 2025-06-10 00:47:12 +0000, olcott said:

    On 6/9/2025 7:26 PM, Richard Damon wrote:
    On 6/9/25 10:43 AM, olcott wrote:
    On 6/9/2025 5:31 AM, Fred. Zwarts wrote:
    Op 09.jun.2025 om 06:15 schreef olcott:
    On 6/8/2025 10:42 PM, dbush wrote:
    On 6/8/2025 11:39 PM, olcott wrote:
    On 6/8/2025 10:32 PM, dbush wrote:
    On 6/8/2025 11:16 PM, olcott wrote:
    On 6/8/2025 10:08 PM, dbush wrote:
    On 6/8/2025 10:50 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>
    No it's not, as halt deciders / termination analyzers work with algorithms,

    That is stupidly counter-factual.


    That you think that shows that

    My understanding is deeper than yours.
    No decider ever takes any algorithm as its input.

    But they take a description/specification of an algorithm,

    There you go.

    which is what is meant in this context.

    It turns out that this detail makes a big difference.

    And because your HHH does not work with the description/ specification of an algorithm, by
    your own admission, you're not working on the halting problem. >>>>>>>>>>

    HHH(DDD) takes a finite string of x86 instructions
    that specify that HHH simulates itself simulating DDD.

    And HHH fails to see the specification of the x86 instructions. It aborts before it can see
    how the program ends.


    This is merely a lack of sufficient technical competence
    on your part. It is a verified fact that unless the outer
    HHH aborts its simulation of DDD that DDD simulated by HHH
    the directly executed DDD() and the directly executed HHH()
    would never stop running. That you cannot directly see this
    is merely your own lack of sufficient technical competence.

    And it is a verified fact that you just ignore that if HHH does in fact abort its simulation
    of DDD and return 0, then the behavior of the input, PER THE ACTUAL DEFINITIONS, is to Halt,
    and thus HHH is just incorrect.


    void DDD()
    {
       HHH(DDD);
       return;
    }

    How the f-ck does DDD correctly simulated by HHH
    reach its own "return" statement final halt state?

    If HHH is not a decider the question is not interesting.
    If HHH is a deider it returns. The first insturunction
    after the return terminates the execution of DDD.

    But then DDD *simulated by HHH* does is not simulated as far as its own return statement.  In
    fact zero steps of DDD are simulated.


    Since I have shown you the execution trace of DDD simulated
    by HHH many times it is gross negligence that you say that
    "zero steps of DDD are simulated."

    Upon closer inspection it seems I misread what Mikko was saying.  I misread that he was suggesting
    an HHH which returned straight away.  So just ignore my "zero steps" remark.

    My other remarks look right:

    -   But then DDD *simulated by HHH* is not simulated as far as its own return statement.
        HINT:  I'm agreeing with you.
        HINT:  Mikko, Fred and Richard have all also agreed with that statement,
               Nobody has agreed that that implies that DDD halts. <=== THAT is your disagreement.
               You're welcome.

    LOL, oh dear, of course I meant:

    Nobody has agreed that that implies that DDD /never/ halts. <=== THAT is
    your disagreement.

    i.e. consistent with the next statement. [I did reread my post before clicking send, but I guess I
    just saw what I expected to see...] Also I should apologise in advance if I've misunderstood
    M/F/R's position - I'm fairly confident they all /have/ agreed that the /simulation/ never proceeds
    as far as DDD's return statement (due to premature abort etc..) I just get fed up reading PO's
    repeated claims that everybody "lies" about that statement, when PO's memory/comprehension skills
    are at fault on this.

    -   Of course, DDD directly executed will reach its own return statement,
        so it is true that this DDD halts...


    Mike.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Jun 10 15:00:12 2025
    On 6/10/25 1:36 PM, olcott wrote:
    On 6/10/2025 11:42 AM, Mike Terry wrote:
    On 10/06/2025 17:17, olcott wrote:
    On 6/10/2025 11:09 AM, Mike Terry wrote:
    On 10/06/2025 12:41, Mikko wrote:
    On 2025-06-10 00:47:12 +0000, olcott said:

    On 6/9/2025 7:26 PM, Richard Damon wrote:
    On 6/9/25 10:43 AM, olcott wrote:
    On 6/9/2025 5:31 AM, Fred. Zwarts wrote:
    Op 09.jun.2025 om 06:15 schreef olcott:
    On 6/8/2025 10:42 PM, dbush wrote:
    On 6/8/2025 11:39 PM, olcott wrote:
    On 6/8/2025 10:32 PM, dbush wrote:
    On 6/8/2025 11:16 PM, olcott wrote:
    On 6/8/2025 10:08 PM, dbush wrote:
    On 6/8/2025 10:50 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>
    No it's not, as halt deciders / termination analyzers >>>>>>>>>>>>>>> work with algorithms,

    That is stupidly counter-factual.


    That you think that shows that

    My understanding is deeper than yours.
    No decider ever takes any algorithm as its input.

    But they take a description/specification of an algorithm, >>>>>>>>>>
    There you go.

    which is what is meant in this context.

    It turns out that this detail makes a big difference.

    And because your HHH does not work with the description/ >>>>>>>>>>> specification of an algorithm, by your own admission, you're >>>>>>>>>>> not working on the halting problem.


    HHH(DDD) takes a finite string of x86 instructions
    that specify that HHH simulates itself simulating DDD.

    And HHH fails to see the specification of the x86 instructions. >>>>>>>>> It aborts before it can see how the program ends.


    This is merely a lack of sufficient technical competence
    on your part. It is a verified fact that unless the outer
    HHH aborts its simulation of DDD that DDD simulated by HHH
    the directly executed DDD() and the directly executed HHH()
    would never stop running. That you cannot directly see this
    is merely your own lack of sufficient technical competence.

    And it is a verified fact that you just ignore that if HHH does
    in fact abort its simulation of DDD and return 0, then the
    behavior of the input, PER THE ACTUAL DEFINITIONS, is to Halt,
    and thus HHH is just incorrect.


    void DDD()
    {
       HHH(DDD);
       return;
    }

    How the f-ck does DDD correctly simulated by HHH
    reach its own "return" statement final halt state?

    If HHH is not a decider the question is not interesting.
    If HHH is a deider it returns. The first insturunction
    after the return terminates the execution of DDD.

    But then DDD *simulated by HHH* does is not simulated as far as its
    own return statement.  In fact zero steps of DDD are simulated.


    Since I have shown you the execution trace of DDD simulated
    by HHH many times it is gross negligence that you say that
    "zero steps of DDD are simulated."

    Upon closer inspection it seems I misread what Mikko was saying.  I
    misread that he was suggesting an HHH which returned straight away.
    So just ignore my "zero steps" remark.


    That is great. I continue to trust that you are honest
    because of all of the evidence that you provided showing
    a very deep and correct understanding of my work.

    My other remarks look right:

    -   But then DDD *simulated by HHH* is not simulated as far as its own
    return statement.
         HINT:  I'm agreeing with you.
         HINT:  Mikko, Fred and Richard have all also agreed with that
    statement,
                Nobody has agreed that that implies that DDD halts. <===
    THAT is your disagreement.
                You're welcome.
    -   Of course, DDD directly executed will reach its own return statement, >>      so it is true that this DDD halts...


    Mike.


    The input to HHH(DDD) specifies non-halting behavior.

    int main()
    {
      DDD(); // calls HHH(DDD)
    }

    The HHH(DDD) that DDD() calls cannot report on the
    behavior of its caller because it can't even see its
    caller. Its caller could have been main() and HHH(DDD)
    has no way to see this.

    Right, so that is why it needs to report on the behavior of the program
    DDD, regardless of whether it is its caller or not.

    I guess you are saying that it is just IMPOSSIBLE to ask a decider about programs, since it can't "see" the actual execution of it.

    STUPID.


    We could define the requirements for an algorithm
    to correctly predict the name of president of the
    United States 4 years from now and its only input
    is a single integer value.

    That would be an error.


    This could not be computable yet does not show any
    actual limitation to computer science. Likewise for
    a termination analyzer that is required to report
    on the behavior of its caller.


    It just shows the limititions of the Olcottian brain, that it can't
    handle the actual concepts of logic.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Jun 10 23:31:04 2025
    On 6/10/25 5:32 PM, olcott wrote:
    On 6/10/2025 2:00 PM, Richard Damon wrote:
    On 6/10/25 1:36 PM, olcott wrote:
    On 6/10/2025 11:42 AM, Mike Terry wrote:
    On 10/06/2025 17:17, olcott wrote:
    On 6/10/2025 11:09 AM, Mike Terry wrote:
    On 10/06/2025 12:41, Mikko wrote:
    On 2025-06-10 00:47:12 +0000, olcott said:

    On 6/9/2025 7:26 PM, Richard Damon wrote:
    On 6/9/25 10:43 AM, olcott wrote:
    On 6/9/2025 5:31 AM, Fred. Zwarts wrote:
    Op 09.jun.2025 om 06:15 schreef olcott:
    On 6/8/2025 10:42 PM, dbush wrote:
    On 6/8/2025 11:39 PM, olcott wrote:
    On 6/8/2025 10:32 PM, dbush wrote:
    On 6/8/2025 11:16 PM, olcott wrote:
    On 6/8/2025 10:08 PM, dbush wrote:
    On 6/8/2025 10:50 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>>>
    No it's not, as halt deciders / termination analyzers >>>>>>>>>>>>>>>>> work with algorithms,

    That is stupidly counter-factual.


    That you think that shows that

    My understanding is deeper than yours.
    No decider ever takes any algorithm as its input.

    But they take a description/specification of an algorithm, >>>>>>>>>>>>
    There you go.

    which is what is meant in this context.

    It turns out that this detail makes a big difference.

    And because your HHH does not work with the description/ >>>>>>>>>>>>> specification of an algorithm, by your own admission, >>>>>>>>>>>>> you're not working on the halting problem.


    HHH(DDD) takes a finite string of x86 instructions
    that specify that HHH simulates itself simulating DDD.

    And HHH fails to see the specification of the x86
    instructions. It aborts before it can see how the program ends. >>>>>>>>>>>

    This is merely a lack of sufficient technical competence
    on your part. It is a verified fact that unless the outer
    HHH aborts its simulation of DDD that DDD simulated by HHH >>>>>>>>>> the directly executed DDD() and the directly executed HHH() >>>>>>>>>> would never stop running. That you cannot directly see this >>>>>>>>>> is merely your own lack of sufficient technical competence. >>>>>>>>>
    And it is a verified fact that you just ignore that if HHH does >>>>>>>>> in fact abort its simulation of DDD and return 0, then the
    behavior of the input, PER THE ACTUAL DEFINITIONS, is to Halt, >>>>>>>>> and thus HHH is just incorrect.


    void DDD()
    {
       HHH(DDD);
       return;
    }

    How the f-ck does DDD correctly simulated by HHH
    reach its own "return" statement final halt state?

    If HHH is not a decider the question is not interesting.
    If HHH is a deider it returns. The first insturunction
    after the return terminates the execution of DDD.

    But then DDD *simulated by HHH* does is not simulated as far as
    its own return statement.  In fact zero steps of DDD are simulated. >>>>>>

    Since I have shown you the execution trace of DDD simulated
    by HHH many times it is gross negligence that you say that
    "zero steps of DDD are simulated."

    Upon closer inspection it seems I misread what Mikko was saying.  I
    misread that he was suggesting an HHH which returned straight away.
    So just ignore my "zero steps" remark.


    That is great. I continue to trust that you are honest
    because of all of the evidence that you provided showing
    a very deep and correct understanding of my work.

    My other remarks look right:

    -   But then DDD *simulated by HHH* is not simulated as far as its
    own return statement.
         HINT:  I'm agreeing with you.
         HINT:  Mikko, Fred and Richard have all also agreed with that >>>> statement,
                Nobody has agreed that that implies that DDD halts. <===
    THAT is your disagreement.
                You're welcome.
    -   Of course, DDD directly executed will reach its own return
    statement,
         so it is true that this DDD halts...


    Mike.


    The input to HHH(DDD) specifies non-halting behavior.

    int main()
    {
       DDD(); // calls HHH(DDD)
    }

    The HHH(DDD) that DDD() calls cannot report on the
    behavior of its caller because it can't even see its
    caller. Its caller could have been main() and HHH(DDD)
    has no way to see this.

    Right, so that is why it needs to report on the behavior of the
    program DDD, regardless of whether it is its caller or not.


    It must report on the behavior that the input to HHH(DDD) specifies.
    The input to HHH(DDD) specifies that HHH simulates DDD and then
    simulates itself simulating DDD.

    Then why isn't that what HHH does?


    I guess you are saying that it is just IMPOSSIBLE to ask a decider
    about programs, since it can't "see" the actual execution of it.

    STUPID.


    HHH(DDD) does correctly reject its input because
    its input would never stop running unless aborted.
    This remains true even when its input is construed
    to include HHH() and everything that HHH calls.

    Nope, just more of your lies.

    If HHH isn't a program, then DDD isn't either (and you have admitted
    this much) and thus the input just can not be simulated so your entire
    claim is a LIE.

    Once you make HHH a program, then by definition it does what it does,
    and since HHH does abort its simulation of DDD, then DDD does halt since
    a correct simulation of it, that goes past the point where HHH aborted
    and returned 0, will see that the simulated HHH will also do exactly
    that, and return to the simulated DDD, which then halts.



    We could define the requirements for an algorithm
    to correctly predict the name of president of the
    United States 4 years from now and its only input
    is a single integer value.

    That would be an error.

    Likewise with the requirement that a halt decider
    report on the behavior of the direct execution of
    DDD() which is its own caller.



    From what?

    Since that *IS* the behavior of the program its input describes, that
    must be what it needs to answer about.

    All you are doing is admitting that you system just can't meet the specifications of the proof program.

    Sorry, you are just proving that you don't understand what you are
    talking about, and have admitted that you have actually been lying out
    of reckless ignorance.

    The fact that you hve stated that you INTENTIONALLY didn't study the
    material and thus don't actually know what you are talking about but
    just making it up.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Wed Jun 11 14:59:19 2025
    Op 10.jun.2025 om 20:45 schreef olcott:
    On 6/10/2025 1:22 PM, Mike Terry wrote:
    On 10/06/2025 17:42, Mike Terry wrote:
    On 10/06/2025 17:17, olcott wrote:
    On 6/10/2025 11:09 AM, Mike Terry wrote:
    On 10/06/2025 12:41, Mikko wrote:
    On 2025-06-10 00:47:12 +0000, olcott said:

    On 6/9/2025 7:26 PM, Richard Damon wrote:
    On 6/9/25 10:43 AM, olcott wrote:
    On 6/9/2025 5:31 AM, Fred. Zwarts wrote:
    Op 09.jun.2025 om 06:15 schreef olcott:
    On 6/8/2025 10:42 PM, dbush wrote:
    On 6/8/2025 11:39 PM, olcott wrote:
    On 6/8/2025 10:32 PM, dbush wrote:
    On 6/8/2025 11:16 PM, olcott wrote:
    On 6/8/2025 10:08 PM, dbush wrote:
    On 6/8/2025 10:50 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>>
    No it's not, as halt deciders / termination analyzers >>>>>>>>>>>>>>>> work with algorithms,

    That is stupidly counter-factual.


    That you think that shows that

    My understanding is deeper than yours.
    No decider ever takes any algorithm as its input.

    But they take a description/specification of an algorithm, >>>>>>>>>>>
    There you go.

    which is what is meant in this context.

    It turns out that this detail makes a big difference.

    And because your HHH does not work with the description/ >>>>>>>>>>>> specification of an algorithm, by your own admission, you're >>>>>>>>>>>> not working on the halting problem.


    HHH(DDD) takes a finite string of x86 instructions
    that specify that HHH simulates itself simulating DDD.

    And HHH fails to see the specification of the x86
    instructions. It aborts before it can see how the program ends. >>>>>>>>>>

    This is merely a lack of sufficient technical competence
    on your part. It is a verified fact that unless the outer
    HHH aborts its simulation of DDD that DDD simulated by HHH
    the directly executed DDD() and the directly executed HHH()
    would never stop running. That you cannot directly see this
    is merely your own lack of sufficient technical competence.

    And it is a verified fact that you just ignore that if HHH does >>>>>>>> in fact abort its simulation of DDD and return 0, then the
    behavior of the input, PER THE ACTUAL DEFINITIONS, is to Halt, >>>>>>>> and thus HHH is just incorrect.


    void DDD()
    {
       HHH(DDD);
       return;
    }

    How the f-ck does DDD correctly simulated by HHH
    reach its own "return" statement final halt state?

    If HHH is not a decider the question is not interesting.
    If HHH is a deider it returns. The first insturunction
    after the return terminates the execution of DDD.

    But then DDD *simulated by HHH* does is not simulated as far as its
    own return statement.  In fact zero steps of DDD are simulated.


    Since I have shown you the execution trace of DDD simulated
    by HHH many times it is gross negligence that you say that
    "zero steps of DDD are simulated."

    Upon closer inspection it seems I misread what Mikko was saying.  I
    misread that he was suggesting an HHH which returned straight away.
    So just ignore my "zero steps" remark.

    My other remarks look right:

    -   But then DDD *simulated by HHH* is not simulated as far as its
    own return statement.
         HINT:  I'm agreeing with you.
         HINT:  Mikko, Fred and Richard have all also agreed with that
    statement,
                Nobody has agreed that that implies that DDD halts. <===
    THAT is your disagreement.
                You're welcome.

    LOL, oh dear, of course I meant:

                   Nobody has agreed that that implies that DDD /never/
    halts. <=== THAT is
                   your disagreement.


    Infinite_Loop()
    {
      HERE: goto HERE;
      return;
    }

    Yet most people here don't know that halts means
    reaching the simulated "return" statement final
    halt state.

    Again it turns out that you doe not understand what people say when they correct you.
    Your definition is incomplete. 'halt means reaching the simulated
    "return" statement final halt state if the simulation/execution is
    complete. (Not aborted.)

    Don't say that it is silly to do an infinite simulation for a
    non-halting program, because to code you show in Halt7.c has only a
    finite recursion, so a finite simulation is enough to reach the 'return' instruction, as world-calls simulators have proven for exactly the same
    input.
    But HHH cannot simulate itself up to the end.

    If you are not dishonest or stubborn, you must have a mental problem to
    learn from corrections by other people.

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