• Re: I have just proven the error of all of the halting problem proofs--- breakthrough ?

    From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Sat Aug 2 09:27:48 2025
    From Newsgroup: comp.ai.philosophy

    On 8/2/2025 4:30 AM, Fred. Zwarts wrote:
    Op 01.aug.2025 om 17:12 schreef olcott:
    On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
    Op 30.jul.2025 om 16:52 schreef olcott:
    On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
    Op 30.jul.2025 om 05:12 schreef olcott:

    This just occurred to me:
    *HHH(DDD)==0 is also correct for another different reason*

    Even if we construed the HHH that DDD calls a part of the
    program under test it is true that neither the simulated
    DDD nor the simulated HHH cannot possibly reach their own
    final halt state.
    Indeed. But there are different reasons:
    The simulating HHH fails to reach the final halt state of the
    simulation because it does a premature abort,
    *I challenge you to show a premature abort*

    This has been presented tro you many times, but you close your eyes
    for it and pretend that it does not exist.>
    _DDD()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6892210000 push 00002192  // push DDD
    [0000219a] e833f4ffff call 000015d2  // call HHH
    [0000219f] 83c404     add esp,+04
    [000021a2] 5d         pop ebp
    [000021a3] c3         ret
    Size in bytes:(0018) [000021a3]

    We have told you that the suggestion that these 18 bytes are the
    whole input is misleading and incorrect. The input also includes all
    function called by DDD, directly or indirectly, including the HHH
    that aborts after a few cycles.
    This input specifies a halting program as other correct simulators
    and direct execution prove.


    Neither the directly executed HHH() the directly executed DDD()
    not DDD correctly simulated by HHH can possibly ever stop running
    unless HHH(DDD) aborts the simulation of its input.

    It is an irrelevant change of subject to imagine a hypothetical non-
    input that has no abort code.


    *Not according to the leading author of theory of computation textbooks*
    <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its
    input D until H correctly determines that its simulated D
    would never stop running unless aborted then

    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
    </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>



    Turing machine halt deciders are only accountable for the
    behavior that their inputs specifies thus the behavior
    of non-input direct executions has always been outside
    of their domain. The DDD correctly simulated by HHH cannot
    possibly halt proves that HHH is correct to reject its input.


    No, it shows that HHH fails to reach the final halt state, where a
    simulator (even when named HHH) that does not abort,has no problem to
    reach the final halt state.


    Where the Hell are you getting that from?

    _DDD()
    [00002192] 55 push ebp
    [00002193] 8bec mov ebp,esp
    [00002195] 6892210000 push 00002192 // push DDD
    [0000219a] e833f4ffff call 000015d2 // call HHH
    [0000219f] 83c404 add esp,+04
    [000021a2] 5d pop ebp
    [000021a3] c3 ret
    Size in bytes:(0018) [000021a3]

    Prove your statement on this code.



    We have been over this too many times. If it actually
    is a premature abort then you could specify the number
    of N instructions of DDD that must be correctly emulated
    by HHH such that DDD reaches its own final halt state.

    As usual a false claim.

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

    _DDD()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6892210000 push 00002192  // push DDD
    [0000219a] e833f4ffff call 000015d2  // call HHH
    [0000219f] 83c404     add esp,+04
    [000021a2] 5d         pop ebp
    [000021a3] c3         ret
    Size in bytes:(0018) [000021a3]

    If there is an actual *premature abort* then there
    is a specific point in the execution trace where
    DDD correctly simulated by HHH stops running without
    ever being aborted. Otherwise you are using the term
    *premature abort* incorrectly.

    Illogical, counter-factual and incorrect claim without evidence.

    What do you mean by premature abort?
    The actual word "premature" means too early.
    If the abort is too early then there is a point
    in the execution trace that is not too early.

    It is exactly the premature abort that causes that the final halt state
    is not reached. Of, course the trace of that prematurely aborted
    simulation does not show the last part of a correct simulation.

    In other words when DDD calls its own simulator HHH in
    recursive simulation this is exactly the same thing as
    DDD never calling its own simulator HHH1 in recursive
    simulation?

    Sounds like 1984 newspeak to me.
    https://en.wikipedia.org/wiki/Newspeak

    But a comparison with a correct simulation done by e.g. HHH1, shows the exact point where the final halt state is reached and where HHH does the premature abort.

    --
    Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Richard Damon@Richard@Damon-Family.org to comp.theory,sci.logic,comp.ai.philosophy on Sat Aug 2 14:46:49 2025
    From Newsgroup: comp.ai.philosophy

    On 8/2/25 10:27 AM, olcott wrote:
    On 8/2/2025 4:30 AM, Fred. Zwarts wrote:
    Op 01.aug.2025 om 17:12 schreef olcott:
    On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
    Op 30.jul.2025 om 16:52 schreef olcott:
    On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
    Op 30.jul.2025 om 05:12 schreef olcott:

    This just occurred to me:
    *HHH(DDD)==0 is also correct for another different reason*

    Even if we construed the HHH that DDD calls a part of the
    program under test it is true that neither the simulated
    DDD nor the simulated HHH cannot possibly reach their own
    final halt state.
    Indeed. But there are different reasons:
    The simulating HHH fails to reach the final halt state of the
    simulation because it does a premature abort,
    *I challenge you to show a premature abort*

    This has been presented tro you many times, but you close your eyes
    for it and pretend that it does not exist.>
    _DDD()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6892210000 push 00002192  // push DDD
    [0000219a] e833f4ffff call 000015d2  // call HHH
    [0000219f] 83c404     add esp,+04
    [000021a2] 5d         pop ebp
    [000021a3] c3         ret
    Size in bytes:(0018) [000021a3]

    We have told you that the suggestion that these 18 bytes are the
    whole input is misleading and incorrect. The input also includes all
    function called by DDD, directly or indirectly, including the HHH
    that aborts after a few cycles.
    This input specifies a halting program as other correct simulators
    and direct execution prove.


    Neither the directly executed HHH() the directly executed DDD()
    not DDD correctly simulated by HHH can possibly ever stop running
    unless HHH(DDD) aborts the simulation of its input.

    It is an irrelevant change of subject to imagine a hypothetical non-
    input that has no abort code.


    *Not according to the leading author of theory of computation textbooks*
    <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
        If simulating halt decider H correctly simulates its
        input D until H correctly determines that its simulated D
        would never stop running unless aborted then

        H can abort its simulation of D and correctly report that D
        specifies a non-halting sequence of configurations.
    </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>



    Turing machine halt deciders are only accountable for the
    behavior that their inputs specifies thus the behavior
    of non-input direct executions has always been outside
    of their domain. The DDD correctly simulated by HHH cannot
    possibly halt proves that HHH is correct to reject its input.


    No, it shows that HHH fails to reach the final halt state, where a
    simulator (even when named HHH) that does not abort,has no problem to
    reach the final halt state.


    Where the Hell are you getting that from?

    _DDD()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6892210000 push 00002192  // push DDD
    [0000219a] e833f4ffff call 000015d2  // call HHH
    [0000219f] 83c404     add esp,+04
    [000021a2] 5d         pop ebp
    [000021a3] c3         ret
    Size in bytes:(0018) [000021a3]

    Prove your statement on this code.



    We have been over this too many times. If it actually
    is a premature abort then you could specify the number
    of N instructions of DDD that must be correctly emulated
    by HHH such that DDD reaches its own final halt state.

    As usual a false claim.

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

    _DDD()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6892210000 push 00002192  // push DDD
    [0000219a] e833f4ffff call 000015d2  // call HHH
    [0000219f] 83c404     add esp,+04
    [000021a2] 5d         pop ebp
    [000021a3] c3         ret
    Size in bytes:(0018) [000021a3]

    If there is an actual *premature abort* then there
    is a specific point in the execution trace where
    DDD correctly simulated by HHH stops running without
    ever being aborted. Otherwise you are using the term
    *premature abort* incorrectly.

    Illogical, counter-factual and incorrect claim without evidence.

    What do you mean by premature abort?
    The actual word "premature" means too early.
    If the abort is too early then there is a point
    in the execution trace that is not too early.

    And that would be when the final state is found, or an ACTUAL PROOF of non-halting can be made. Your "proof" fails, as it looks at a different
    input, the DDD that calls the non-aborting HHH.


    It is exactly the premature abort that causes that the final halt
    state is not reached. Of, course the trace of that prematurely aborted
    simulation does not show the last part of a correct simulation.

    In other words when DDD calls its own simulator HHH in
    recursive simulation this is exactly the same thing as
    DDD never calling its own simulator HHH1 in recursive
    simulation?

    Right, becuase in both cases it calls the exact same program HHH.

    It doesn't CARE who is simulating it, as simulation is objective, and
    thus doesn't matter who does it.

    IF you want to try to show why it matters, show what instruciton changed behavior per the x86 language.

    Your failure has shown your stupidity.


    Sounds like 1984 newspeak to me.
    https://en.wikipedia.org/wiki/Newspeak

    Nope, YOURS does, as you seem to think that something that doesn't
    matter is the most important thing in the world.


    But a comparison with a correct simulation done by e.g. HHH1, shows
    the exact point where the final halt state is reached and where HHH
    does the premature abort.





    --- Synchronet 3.21a-Linux NewsLink 1.2