• Why Peter Olcott is correct

    From Mr Flibble@21:1/5 to All on Sun May 18 00:11:22 2025
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a
    correct halting result *as if* the simulation was run to completion:
    whether we abort, or continue until we run out of stack space makes no difference: we are detecting INFINITE recursion which can be viewed as non- halting.

    This is valid due to Flibble's Law:

    If a problem permits infinite behavior in its formulation, it permits
    infinite analysis of that behavior in its decidability scope.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Mr Flibble on Sun May 18 02:06:43 2025
    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a
    correct halting result *as if* the simulation was run to completion:

    Right. If the simulation is run to completion, that's like a UTM simulating the input, and
    equivalent to asking whether the input halts. This is the case for all inputs, not just
    "pathological" ones, whatever they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation. If that DD is simulated to
    completion it halts, so that is what his SHD needs to report. PO has verified this directly, and
    has published the traces showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes no difference: we are detecting INFINITE recursion which can be viewed as non- halting.

    Eh? PO does have a couple of SHDs that simulate his DD to completion, and they all show DD halting!
    There's no infinite recursion, only some level of finite recursive simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to completion. It aborts, and
    then decides non-halting. That's the reverse of what you said in the first paragraph. So your
    thread title is misleading - PO is actually *incorrect*. I've corrected the title to avoid confusion.


    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to Mike Terry on Sun May 18 01:10:10 2025
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a
    correct halting result *as if* the simulation was run to completion:

    Right. If the simulation is run to completion, that's like a UTM
    simulating the input, and equivalent to asking whether the input halts.
    This is the case for all inputs, not just "pathological" ones, whatever
    they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation. If that
    DD is simulated to completion it halts, so that is what his SHD needs to report. PO has verified this directly, and has published the traces
    showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes no
    difference: we are detecting INFINITE recursion which can be viewed as
    non-
    halting.

    Eh? PO does have a couple of SHDs that simulate his DD to completion,
    and they all show DD halting!
    There's no infinite recursion, only some level of finite recursive
    simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to completion. It aborts, and then decides non-halting. That's the
    reverse of what you said in the first paragraph. So your thread title
    is misleading - PO is actually *incorrect*. I've corrected the title to avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of HALTING
    for what is being simulated. I have changed the subject title back, you jackass.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to Mike Terry on Sun May 18 01:51:25 2025
    On Sun, 18 May 2025 02:42:58 +0100, Mike Terry wrote:

    On 18/05/2025 02:10, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a
    correct halting result *as if* the simulation was run to completion:

    Right. If the simulation is run to completion, that's like a UTM
    simulating the input, and equivalent to asking whether the input
    halts. This is the case for all inputs, not just "pathological" ones,
    whatever they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation. If
    that DD is simulated to completion it halts, so that is what his SHD
    needs to report. PO has verified this directly, and has published the
    traces showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes
    no difference: we are detecting INFINITE recursion which can be
    viewed as non-
    halting.

    Eh? PO does have a couple of SHDs that simulate his DD to completion,
    and they all show DD halting!
    There's no infinite recursion, only some level of finite recursive
    simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to
    completion. It aborts, and then decides non-halting. That's the
    reverse of what you said in the first paragraph. So your thread title
    is misleading - PO is actually *incorrect*. I've corrected the title
    to avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of
    HALTING for what is being simulated. I have changed the subject title
    back, you jackass.

    Where did I say it was the same? /YOU/ said above that PO's SHD should decide *as if* the simulation was run to completion. [your
    highlighting]. If DD is simulated to completion it halts,
    so by your logic his SHD should decide halting. Instead it decides neverhalts.

    No, if an IDEAL simulation runs to completion it NEVER completes as the recursion is INFINITE however a practical simulator has finite resources
    (and a valid decider must decide in finite time) so cannot run forever so instead we abort the simulation early if we detect infinite recursion with
    a correct halting result of NON-HALTING. This is in accordance with
    Flibble's Law.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Mr Flibble on Sun May 18 02:42:58 2025
    On 18/05/2025 02:10, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a
    correct halting result *as if* the simulation was run to completion:

    Right. If the simulation is run to completion, that's like a UTM
    simulating the input, and equivalent to asking whether the input halts.
    This is the case for all inputs, not just "pathological" ones, whatever
    they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation. If that
    DD is simulated to completion it halts, so that is what his SHD needs to
    report. PO has verified this directly, and has published the traces
    showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes no
    difference: we are detecting INFINITE recursion which can be viewed as
    non-
    halting.

    Eh? PO does have a couple of SHDs that simulate his DD to completion,
    and they all show DD halting!
    There's no infinite recursion, only some level of finite recursive
    simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to
    completion. It aborts, and then decides non-halting. That's the
    reverse of what you said in the first paragraph. So your thread title
    is misleading - PO is actually *incorrect*. I've corrected the title to
    avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of HALTING
    for what is being simulated. I have changed the subject title back, you jackass.

    Where did I say it was the same? /YOU/ said above that PO's SHD should decide *as if* the
    simulation was run to completion. [your highlighting]. If DD is simulated to completion it halts,
    so by your logic his SHD should decide halting. Instead it decides neverhalts.

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Mr Flibble on Sun May 18 03:06:42 2025
    On 18/05/2025 02:51, Mr Flibble wrote:
    On Sun, 18 May 2025 02:42:58 +0100, Mike Terry wrote:

    On 18/05/2025 02:10, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a >>>>> correct halting result *as if* the simulation was run to completion:

    Right. If the simulation is run to completion, that's like a UTM
    simulating the input, and equivalent to asking whether the input
    halts. This is the case for all inputs, not just "pathological" ones,
    whatever they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation. If
    that DD is simulated to completion it halts, so that is what his SHD
    needs to report. PO has verified this directly, and has published the >>>> traces showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes
    no difference: we are detecting INFINITE recursion which can be
    viewed as non-
    halting.

    Eh? PO does have a couple of SHDs that simulate his DD to completion, >>>> and they all show DD halting!
    There's no infinite recursion, only some level of finite recursive >>>> simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to
    completion. It aborts, and then decides non-halting. That's the
    reverse of what you said in the first paragraph. So your thread title >>>> is misleading - PO is actually *incorrect*. I've corrected the title
    to avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of
    HALTING for what is being simulated. I have changed the subject title
    back, you jackass.

    Where did I say it was the same? /YOU/ said above that PO's SHD should
    decide *as if* the simulation was run to completion. [your
    highlighting]. If DD is simulated to completion it halts,
    so by your logic his SHD should decide halting. Instead it decides
    neverhalts.

    No, if an IDEAL simulation runs to completion it NEVER completes as the recursion is INFINITE however a practical simulator has finite resources
    (and a valid decider must decide in finite time) so cannot run forever so instead we abort the simulation early if we detect infinite recursion with
    a correct halting result of NON-HALTING. This is in accordance with Flibble's Law.

    /Flibble


    As I said above, the recursion in the case of PO's DD is NOT INFINITE. This isn't about "IDEAL"
    simulations having unbounded resources or anything like that. The simulation of DD completes with
    DD returning really quickly, using very modest resources. I'd say "try it for yourself", but you'd
    have to build PO's x86utm first. It's not about resources - DD /really does halt/!

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to olcott on Sun May 18 02:32:10 2025
    On Sat, 17 May 2025 21:28:23 -0500, olcott wrote:

    On 5/17/2025 8:10 PM, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a
    correct halting result *as if* the simulation was run to completion:

    Right. If the simulation is run to completion, that's like a UTM
    simulating the input, and equivalent to asking whether the input
    halts. This is the case for all inputs, not just "pathological" ones,
    whatever they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation. If
    that DD is simulated to completion it halts, so that is what his SHD
    needs to report. PO has verified this directly, and has published the
    traces showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes
    no difference: we are detecting INFINITE recursion which can be
    viewed as non-
    halting.

    Eh? PO does have a couple of SHDs that simulate his DD to completion,
    and they all show DD halting!
    There's no infinite recursion, only some level of finite recursive
    simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to
    completion. It aborts, and then decides non-halting. That's the
    reverse of what you said in the first paragraph. So your thread title
    is misleading - PO is actually *incorrect*. I've corrected the title
    to avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of
    HALTING for what is being simulated. I have changed the subject title
    back, you jackass.

    /Flibble

    He is only terribly wrong on this one point. Mike has by far the most complete understanding of my work than anyone else in the world.

    He may have never heard of the *Strawman Fallacy*
    Description: Substituting a person’s actual position or argument with a distorted, exaggerated, or misrepresented version of the position of the argument. https://www.logicallyfallacious.com/logicalfallacies/Strawman-Fallacy

    He even showed exactly how the words Professor Sipser agreed to do
    derive a correct simulating termination analyzer.

    On 5/14/2025 7:36 PM, Mike Terry wrote:
    https://al.howardknight.net/?
    STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E


    Before Mike's succinct and correct reply all of my reviewers were having
    fun playing sadistic head games insisting on only talking in endless
    circles.

    Yes, I am getting that impression too: this is the problem with learn by
    rote vs genuine understanding, no critical thinking.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Sun May 18 11:58:06 2025
    Op 18.mei.2025 om 05:01 schreef olcott:
    On 5/17/2025 8:42 PM, Mike Terry wrote:
    On 18/05/2025 02:10, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a >>>>> correct halting result *as if* the simulation was run to completion:

    Right.  If the simulation is run to completion, that's like a UTM
    simulating the input, and equivalent to asking whether the input halts. >>>> This is the case for all inputs, not just "pathological" ones, whatever >>>> they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation.  If that >>>> DD is simulated to completion it halts, so that is what his SHD
    needs to
    report.  PO has verified this directly, and has published the traces
    showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes no >>>>> difference: we are detecting INFINITE recursion which can be viewed as >>>>> non-
    halting.

    Eh?  PO does have a couple of SHDs that simulate his DD to completion, >>>> and they all show DD halting!
       There's no infinite recursion, only some level of finite recursive >>>>    simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to
    completion.  It aborts, and then decides non-halting.  That's the
    reverse of what you said in the first paragraph.  So your thread title >>>> is misleading - PO is actually *incorrect*.  I've corrected the
    title to
    avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of
    HALTING
    for what is being simulated.  I have changed the subject title back, you >>> jackass.

    Where did I say it was the same?  /YOU/ said above that PO's SHD
    should decide *as if* the simulation was run to completion.  [your
    highlighting].  If DD is simulated to completion it halts, so by your
    logic his SHD should decide halting.  Instead it decides neverhalts.

    Mike.


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

    *DDD simulated by HHH HAS NO COMPLETION*

    Stop dreaming of an infinite recursion when your code includes the abort
    code. Indeed, the simulation is not complete, but it has an incorrect
    end, because of the abort. This causes a program that halts.
    Stop your dreams and face the facts. Come out of rebuttal mode.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to Mr Flibble on Sun May 18 13:03:24 2025
    On 2025-05-18 00:11:22 +0000, Mr Flibble said:

    In the case of pathological input, Peter's SHD only needs to report a
    correct halting result *as if* the simulation was run to completion:
    whether we abort, or continue until we run out of stack space makes no difference:

    You so far you are right. But that is not what Olcott says: he claims
    that HHH may correclty report "does not halt" when the actual input
    specifies a halting computation.

    we are detecting INFINITE recursion which can be viewed as non-
    halting.

    That infinte recursion is not in the input as can be proven by
    an execution of the program specified by the input:

    in main (void) {
    output("Asking HHH.");
    if (HHH(DDD)) {
    output("HHH says DDD halts.");
    } else {
    output("HHH says DDD does not halt.");
    }
    output("Trying DDD.");
    DDD();
    output("DDD has halted.");
    }

    There are functions for output in Olcott's library.

    Olcott is wrong as shown many times. You are wrong about Olcott.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sun May 18 13:08:52 2025
    On 2025-05-18 03:09:44 +0000, olcott said:

    On 5/17/2025 9:06 PM, Mike Terry wrote:
    On 18/05/2025 02:51, Mr Flibble wrote:
    On Sun, 18 May 2025 02:42:58 +0100, Mike Terry wrote:

    On 18/05/2025 02:10, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a >>>>>>> correct halting result *as if* the simulation was run to completion: >>>>>>
    Right.  If the simulation is run to completion, that's like a UTM >>>>>> simulating the input, and equivalent to asking whether the input
    halts. This is the case for all inputs, not just "pathological" ones, >>>>>> whatever they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation.  If >>>>>> that DD is simulated to completion it halts, so that is what his SHD >>>>>> needs to report.  PO has verified this directly, and has published the >>>>>> traces showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes >>>>>>> no difference: we are detecting INFINITE recursion which can be
    viewed as non-
    halting.

    Eh?  PO does have a couple of SHDs that simulate his DD to completion, >>>>>> and they all show DD halting!
        There's no infinite recursion, only some level of finite recursive
        simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to >>>>>> completion.  It aborts, and then decides non-halting.  That's the >>>>>> reverse of what you said in the first paragraph.  So your thread title >>>>>> is misleading - PO is actually *incorrect*.  I've corrected the title >>>>>> to avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of
    HALTING for what is being simulated.  I have changed the subject title >>>>> back, you jackass.

    Where did I say it was the same?  /YOU/ said above that PO's SHD should >>>> decide *as if* the simulation was run to completion.  [your
    highlighting].  If DD is simulated to completion it halts,
    so by your logic his SHD should decide halting.  Instead it decides
    neverhalts.

    No, if an IDEAL simulation runs to completion it NEVER completes as the
    recursion is INFINITE however a practical simulator has finite resources >>> (and a valid decider must decide in finite time) so cannot run forever so >>> instead we abort the simulation early if we detect infinite recursion with >>> a correct halting result of NON-HALTING.  This is in accordance with
    Flibble's Law.

    /Flibble


    As I said above, the recursion in the case of PO's DD is NOT INFINITE.

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

    That program obviously halts if HHH is a decider. If you put any other
    decider in place of HHH (e.g., with a #define line at the top) you get
    a program that halts, too. You may get a non-haltng program if HHH is
    not a decider or you put a non-decider in place of HHH.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Sun May 18 12:11:14 2025
    Op 18.mei.2025 om 05:09 schreef olcott:
    On 5/17/2025 9:06 PM, Mike Terry wrote:
    On 18/05/2025 02:51, Mr Flibble wrote:
    On Sun, 18 May 2025 02:42:58 +0100, Mike Terry wrote:

    On 18/05/2025 02:10, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to
    report a
    correct halting result *as if* the simulation was run to completion: >>>>>>
    Right.  If the simulation is run to completion, that's like a UTM >>>>>> simulating the input, and equivalent to asking whether the input
    halts. This is the case for all inputs, not just "pathological" ones, >>>>>> whatever they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation.  If >>>>>> that DD is simulated to completion it halts, so that is what his SHD >>>>>> needs to report.  PO has verified this directly, and has published >>>>>> the
    traces showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes >>>>>>> no difference: we are detecting INFINITE recursion which can be
    viewed as non-
    halting.

    Eh?  PO does have a couple of SHDs that simulate his DD to
    completion,
    and they all show DD halting!
        There's no infinite recursion, only some level of finite
    recursive
        simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to >>>>>> completion.  It aborts, and then decides non-halting.  That's the >>>>>> reverse of what you said in the first paragraph.  So your thread
    title
    is misleading - PO is actually *incorrect*.  I've corrected the title >>>>>> to avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of
    HALTING for what is being simulated.  I have changed the subject title >>>>> back, you jackass.

    Where did I say it was the same?  /YOU/ said above that PO's SHD should >>>> decide *as if* the simulation was run to completion.  [your
    highlighting].  If DD is simulated to completion it halts,
    so by your logic his SHD should decide halting.  Instead it decides
    neverhalts.

    No, if an IDEAL simulation runs to completion it NEVER completes as the
    recursion is INFINITE however a practical simulator has finite resources >>> (and a valid decider must decide in finite time) so cannot run
    forever so
    instead we abort the simulation early if we detect infinite recursion
    with
    a correct halting result of NON-HALTING.  This is in accordance with
    Flibble's Law.

    /Flibble


    As I said above, the recursion in the case of PO's DD is NOT INFINITE.

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

    Then show how *DDD SIMULATED BY HHH* halts.
    *Its like you don't even know what recursion is*



    The simulation of DDD by HHH1, includes the call from DDD to HHH, which simulates DDD. You claim that this simulation of DDD by HHH is a correct simulation and the simulation by HHH1 shows that the simulation of DDD
    by HHH halts.
    Why dreaming of an infinite recursion, when your code includes code to
    abort? The infinite recursion is only in your dreams. In the actual
    code, there is no infinite recursion. Of course, it is not correct to
    abort the halting code, but this abort is also the reason why the input specifies a halting program.
    It has been proven that no correct code is possible, why do you keep
    asking for a correction. Is 'does not exist' over your head?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sun May 18 13:12:01 2025
    On 2025-05-18 03:01:29 +0000, olcott said:

    On 5/17/2025 8:42 PM, Mike Terry wrote:
    On 18/05/2025 02:10, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a >>>>> correct halting result *as if* the simulation was run to completion:

    Right.  If the simulation is run to completion, that's like a UTM
    simulating the input, and equivalent to asking whether the input halts. >>>> This is the case for all inputs, not just "pathological" ones, whatever >>>> they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation.  If that >>>> DD is simulated to completion it halts, so that is what his SHD needs to >>>> report.  PO has verified this directly, and has published the traces
    showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes no >>>>> difference: we are detecting INFINITE recursion which can be viewed as >>>>> non-
    halting.

    Eh?  PO does have a couple of SHDs that simulate his DD to completion, >>>> and they all show DD halting!
       There's no infinite recursion, only some level of finite recursive >>>>    simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to
    completion.  It aborts, and then decides non-halting.  That's the
    reverse of what you said in the first paragraph.  So your thread title >>>> is misleading - PO is actually *incorrect*.  I've corrected the title to >>>> avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of HALTING >>> for what is being simulated.  I have changed the subject title back, you >>> jackass.

    Where did I say it was the same?  /YOU/ said above that PO's SHD should
    decide *as if* the simulation was run to completion.  [your
    highlighting].  If DD is simulated to completion it halts, so by your
    logic his SHD should decide halting.  Instead it decides neverhalts.

    Mike.


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

    *DDD simulated by HHH HAS NO COMPLETION*

    *DDD simulated by HHH1 IS THE STRAWMAN FALLACY*
    changing the words of the argument and then
    rebutting these changed words.

    Strawman Fallacy
    Description: Substituting a person’s actual position or argument
    with a distorted, exaggerated, or misrepresented version of the
    position of the argument.

    https://www.logicallyfallacious.com/logicalfallacies/Strawman-Fallacy

    We understand straw man fallacy. It is unlikely to work on people who understand it. You have tried it many times but has it ever worked?

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to Mr Flibble on Sun May 18 13:17:07 2025
    On 2025-05-18 02:32:10 +0000, Mr Flibble said:

    On Sat, 17 May 2025 21:28:23 -0500, olcott wrote:

    On 5/17/2025 8:10 PM, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a >>>>> correct halting result *as if* the simulation was run to completion:

    Right. If the simulation is run to completion, that's like a UTM
    simulating the input, and equivalent to asking whether the input
    halts. This is the case for all inputs, not just "pathological" ones,
    whatever they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation. If
    that DD is simulated to completion it halts, so that is what his SHD
    needs to report. PO has verified this directly, and has published the >>>> traces showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes
    no difference: we are detecting INFINITE recursion which can be
    viewed as non-
    halting.

    Eh? PO does have a couple of SHDs that simulate his DD to completion, >>>> and they all show DD halting!
    There's no infinite recursion, only some level of finite recursive
    simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to
    completion. It aborts, and then decides non-halting. That's the
    reverse of what you said in the first paragraph. So your thread title >>>> is misleading - PO is actually *incorrect*. I've corrected the title
    to avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of
    HALTING for what is being simulated. I have changed the subject title
    back, you jackass.

    /Flibble

    He is only terribly wrong on this one point. Mike has by far the most
    complete understanding of my work than anyone else in the world.

    He may have never heard of the *Strawman Fallacy*
    Description: Substituting a person’s actual position or argument with a
    distorted, exaggerated, or misrepresented version of the position of the
    argument.
    https://www.logicallyfallacious.com/logicalfallacies/Strawman-Fallacy

    He even showed exactly how the words Professor Sipser agreed to do
    derive a correct simulating termination analyzer.

    On 5/14/2025 7:36 PM, Mike Terry wrote:
    https://al.howardknight.net/?
    STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E


    Before Mike's succinct and correct reply all of my reviewers were having
    fun playing sadistic head games insisting on only talking in endless
    circles.

    Yes, I am getting that impression too: this is the problem with learn by
    rote vs genuine understanding, no critical thinking.

    Some participants of these discussions are are very poor both at learning
    by rote and at critical thinking.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sun May 18 07:12:22 2025
    On 5/17/25 11:09 PM, olcott wrote:
    On 5/17/2025 9:06 PM, Mike Terry wrote:
    On 18/05/2025 02:51, Mr Flibble wrote:
    On Sun, 18 May 2025 02:42:58 +0100, Mike Terry wrote:

    On 18/05/2025 02:10, Mr Flibble wrote:
    On Sun, 18 May 2025 02:06:43 +0100, Mike Terry wrote:

    On 18/05/2025 01:11, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to
    report a
    correct halting result *as if* the simulation was run to completion: >>>>>>
    Right.  If the simulation is run to completion, that's like a UTM >>>>>> simulating the input, and equivalent to asking whether the input
    halts. This is the case for all inputs, not just "pathological" ones, >>>>>> whatever they are exactly.

    PO's DD() calls an "embedded HHH" which aborts its simulation.  If >>>>>> that DD is simulated to completion it halts, so that is what his SHD >>>>>> needs to report.  PO has verified this directly, and has published >>>>>> the
    traces showing DD halting when simulated to completion.

    whether we abort, or continue until we run out of stack space makes >>>>>>> no difference: we are detecting INFINITE recursion which can be
    viewed as non-
    halting.

    Eh?  PO does have a couple of SHDs that simulate his DD to
    completion,
    and they all show DD halting!
        There's no infinite recursion, only some level of finite
    recursive
        simulation.

    PO gets confused, because his SHD HHH simply /doesn't/ simulate DD to >>>>>> completion.  It aborts, and then decides non-halting.  That's the >>>>>> reverse of what you said in the first paragraph.  So your thread
    title
    is misleading - PO is actually *incorrect*.  I've corrected the title >>>>>> to avoid confusion.

    No, halting the simulation is NOT THE SAME as a halting result of
    HALTING for what is being simulated.  I have changed the subject title >>>>> back, you jackass.

    Where did I say it was the same?  /YOU/ said above that PO's SHD should >>>> decide *as if* the simulation was run to completion.  [your
    highlighting].  If DD is simulated to completion it halts,
    so by your logic his SHD should decide halting.  Instead it decides
    neverhalts.

    No, if an IDEAL simulation runs to completion it NEVER completes as the
    recursion is INFINITE however a practical simulator has finite resources >>> (and a valid decider must decide in finite time) so cannot run
    forever so
    instead we abort the simulation early if we detect infinite recursion
    with
    a correct halting result of NON-HALTING.  This is in accordance with
    Flibble's Law.

    /Flibble


    As I said above, the recursion in the case of PO's DD is NOT INFINITE.

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

    Then show how *DDD SIMULATED BY HHH* halts.
    *Its like you don't even know what recursion is*

    THe problem is you have admitted that your DDD isn't a program and thus
    isn't valid.

    Also, the question is not does DDD simulated by HHH reach the final
    state but does the correct simulation of DDD reach a final state.

    You can only use the simulation of HHH if it is correct, which means it
    can not abort, and thus isn't the HHH that you claim to be correct.


    When I say that Donald Trump is a convicted
    felon and you say "no you are wrong Pope Leo XIV
    is not a convicted felon" you changed my words
    and then rebutted the changed words.

    Right, and the DDD that calls the HHH that doesn't abort is not the same program as the DDD that calls the HHH that does abort, and thus you
    example shows exactly what you yourself are doing.


    Likewise with
    DDD simulated by HHH
    versus
    DDD simulated by HHH1.


    Which just shows that if DDD is the same, that HHH got the wrong answer
    by its aborting.

    Just like Donald Trump being a convicted felon didn't change by him
    being elected as president, only posponed the results of that conviction.

    The fact that HHH aborts its simulation means that HHH didn't reveal the
    full behavior of its input, and thus it doesn't know what happens. It is
    like Mr Trump saying he didn't do anything wrong because all the legal proceedings are paused. He still did the crimes.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to Mr Flibble on Sun May 18 07:05:24 2025
    On 5/17/25 8:11 PM, Mr Flibble wrote:
    Hi!

    In the case of pathological input, Peter's SHD only needs to report a
    correct halting result *as if* the simulation was run to completion:
    whether we abort, or continue until we run out of stack space makes no difference: we are detecting INFINITE recursion which can be viewed as non- halting.

    This is valid due to Flibble's Law:

    If a problem permits infinite behavior in its formulation, it permits infinite analysis of that behavior in its decidability scope.

    /Flibble

    Right, but if the input is the actual program as derived in the halting
    proof, then the simulation, if run to completion will halt, and does not
    show infinite behavior of any form.

    The DDD given as the input is built from the HHH that is claimed to get
    the right answer, and thus is the HHH that will abort at some point and
    return 0.

    The code for that HHH that does that is made part of the program DDD,
    and is encoded in the input.

    Therefore the correct simulation of that input by the hypothetical HHH,
    which is given that same input, which has the aborting code, will see
    tht it will reach the end.

    The error that Olcott makes is the type error of giving a non-leaf
    function, without all the code needed as an input when it needs to be a program. His input is just invalid, and shows that he doesn't understand
    what he is talking about.

    Agreeing with him will also show the same confusion.

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