• 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 Tue Jul 29 22:12:42 2025
    From Newsgroup: comp.ai.philosophy

    On 7/29/2025 8:51 PM, Richard Damon wrote:
    On 7/29/25 9:24 PM, olcott wrote:
    On 7/29/2025 5:37 PM, Richard Damon wrote:
    On 7/29/25 12:53 PM, olcott wrote:
    On 7/28/2025 8:56 PM, Richard Damon wrote:
    On 7/28/25 7:58 PM, olcott wrote:
    On 7/28/2025 6:49 PM, Richard Damon wrote:
    On 7/28/25 7:20 PM, olcott wrote:
    On 7/28/2025 5:57 PM, Richard Damon wrote:
    On 7/28/25 9:54 AM, olcott wrote:
    On 7/28/2025 8:21 AM, joes wrote:
    Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
    On 7/28/2025 2:30 AM, joes wrote:
    Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:
    On 7/27/2025 9:48 PM, Richard Damon wrote:
    On 7/27/25 8:20 PM, olcott wrote:

    When DDD is emulated by HHH1 it need not emulate itself >>>>>>>>>>>>>>>> at all.
    But "itself" doesn't matter to x86 instructions,
    By itself I mean the exact same machine code bytes at the >>>>>>>>>>>>>> exact same
    machine address.
    Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>> change DDD.
    HHH is never changed.

    It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>> is reporting
    on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>> halting DDD,
    and definitely not on HHH(DDD), itself.


    All halt deciders are required to predict the behavior
    of their input. HHH does correctly predict that DDD correctly >>>>>>>>>> simulated by HHH cannot possibly reach its own simulated
    "return" instruction final halt state.


    How is it a "correct prediction" if it sees something different >>>>>>>>> than what that DDD does.


    What DDD does is keep calling HHH(DDD) in recursive
    simulation until HHH kills this whole process.

    But the behavior of the program continues past that (something
    you don't seem to understand) and that behavior will also have
    its HHH terminate the DDD it is simulating and return 0 to DDD
    and then Halt.

    Your problem is you don't understand that the simulating HHH
    doesn't define the behavior of DDD, it is the execution of DDD
    that defines what a correct simulation of it is.


    Remember, to have simulated that DDD, it must have include the >>>>>>>>> code of the HHH that it was based on, which is the HHH that >>>>>>>>> made the prediction, and thus returns 0, so DDD will halt.


    We are not asking: Does DDD() halt.
    That is (as it turns out) an incorrect question.

    No, that is EXACTLY the question.

    I guess you are just admitting that you whole world is based on >>>>>>> LYING about what things are supposed to be.


    Turing machines cannot directly report on the behavior
    of other Turing machines they can at best indirectly
    report on the behavior of Turing machines through the
    proxy of finite string machine descriptions such as ⟨M⟩.

    Right, and HHH was given the equivalenet of (M) by being given
    the code of *ALL* of DDD

    I guess you don't understand that fact, even though you CLAIM the >>>>>>> input is the proper representation of DDD.


    Thus the behavior specified by the input finite string
    overrules and supersedes the behavior of the direct
    execution.

    No, it is DEFINED to be the behavior of the direct execution of >>>>>>> the program it represent.


    *That has always been the fatal flaw of all of the proofs*

    No, your failure to follow the rules is what makes you just a liar.


    _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]

    When the above code is in the same memory space as HHH
    such that DDD calls HHH(DDD) and then HHH does emulate
    itself emulating DDD then this does specify recursive
    emulation.

    Anyone or anything that disagrees would be disagreeing
    with the definition of the x86 language.


    So, if HHH accesses that memory, it becomes part of the input.


    It becomes part of the input in the sense that the
    correct simulation of the input to HHH(DDD) is not
    the same as the correct simulation of the input to
    HHH1(DDD) because DDD only calls HHH(DDD) and does
    not call HHH1(DDD).

    DDD correctly simulated by HHH cannot possibly
    halt thus HHH(DDD)==0 is correct.

    DDD correctly simulated by HHH1 does halt thus
    HHH(DDD)==1 is correct.



    It either *IS* or it *ISN'T* there is no middle.


    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.
    --
    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 Fred. Zwarts@F.Zwarts@HetNet.nl to comp.theory,sci.logic,comp.ai.philosophy on Wed Jul 30 11:23:19 2025
    From Newsgroup: comp.ai.philosophy

    Op 30.jul.2025 om 05:12 schreef olcott:
    On 7/29/2025 8:51 PM, Richard Damon wrote:
    On 7/29/25 9:24 PM, olcott wrote:
    On 7/29/2025 5:37 PM, Richard Damon wrote:
    On 7/29/25 12:53 PM, olcott wrote:
    On 7/28/2025 8:56 PM, Richard Damon wrote:
    On 7/28/25 7:58 PM, olcott wrote:
    On 7/28/2025 6:49 PM, Richard Damon wrote:
    On 7/28/25 7:20 PM, olcott wrote:
    On 7/28/2025 5:57 PM, Richard Damon wrote:
    On 7/28/25 9:54 AM, olcott wrote:
    On 7/28/2025 8:21 AM, joes wrote:
    Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
    On 7/28/2025 2:30 AM, joes wrote:
    Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
    On 7/27/25 8:20 PM, olcott wrote:

    When DDD is emulated by HHH1 it need not emulate itself >>>>>>>>>>>>>>>>> at all.
    But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at the >>>>>>>>>>>>>>> exact same
    machine address.
    Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>> change DDD.
    HHH is never changed.

    It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>>> is reporting
    on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>>> halting DDD,
    and definitely not on HHH(DDD), itself.


    All halt deciders are required to predict the behavior
    of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>> "return" instruction final halt state.


    How is it a "correct prediction" if it sees something
    different than what that DDD does.


    What DDD does is keep calling HHH(DDD) in recursive
    simulation until HHH kills this whole process.

    But the behavior of the program continues past that (something >>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>> and then Halt.

    Your problem is you don't understand that the simulating HHH
    doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>> that defines what a correct simulation of it is.


    Remember, to have simulated that DDD, it must have include the >>>>>>>>>> code of the HHH that it was based on, which is the HHH that >>>>>>>>>> made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>

    We are not asking: Does DDD() halt.
    That is (as it turns out) an incorrect question.

    No, that is EXACTLY the question.

    I guess you are just admitting that you whole world is based on >>>>>>>> LYING about what things are supposed to be.


    Turing machines cannot directly report on the behavior
    of other Turing machines they can at best indirectly
    report on the behavior of Turing machines through the
    proxy of finite string machine descriptions such as ⟨M⟩.

    Right, and HHH was given the equivalenet of (M) by being given >>>>>>>> the code of *ALL* of DDD

    I guess you don't understand that fact, even though you CLAIM >>>>>>>> the input is the proper representation of DDD.


    Thus the behavior specified by the input finite string
    overrules and supersedes the behavior of the direct
    execution.

    No, it is DEFINED to be the behavior of the direct execution of >>>>>>>> the program it represent.


    *That has always been the fatal flaw of all of the proofs*

    No, your failure to follow the rules is what makes you just a liar. >>>>>>

    _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]

    When the above code is in the same memory space as HHH
    such that DDD calls HHH(DDD) and then HHH does emulate
    itself emulating DDD then this does specify recursive
    emulation.

    Anyone or anything that disagrees would be disagreeing
    with the definition of the x86 language.


    So, if HHH accesses that memory, it becomes part of the input.


    It becomes part of the input in the sense that the
    correct simulation of the input to HHH(DDD) is not
    the same as the correct simulation of the input to
    HHH1(DDD) because DDD only calls HHH(DDD) and does
    not call HHH1(DDD).

    DDD correctly simulated by HHH cannot possibly
    halt thus HHH(DDD)==0 is correct.

    DDD correctly simulated by HHH1 does halt thus
    HHH(DDD)==1 is correct.



    It either *IS* or it *ISN'T* there is no middle.


    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, based on the wrong assumption that a
    finite recursion specifies non-halting. Then the simulating HHH does
    reach its own halt state when it reports non-halting.
    The simulated HHH, that has a similar final halt state after it aborts,
    does not reach it own final halt state, because the simulating HHH does
    not allow it to reach it by the premature abort done by the simulating HHH.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Richard Damon@Richard@Damon-Family.org to comp.theory,sci.logic,comp.ai.philosophy on Wed Jul 30 06:59:24 2025
    From Newsgroup: comp.ai.philosophy

    On 7/29/25 11:12 PM, olcott wrote:
    On 7/29/2025 8:51 PM, Richard Damon wrote:
    On 7/29/25 9:24 PM, olcott wrote:
    On 7/29/2025 5:37 PM, Richard Damon wrote:
    On 7/29/25 12:53 PM, olcott wrote:
    On 7/28/2025 8:56 PM, Richard Damon wrote:
    On 7/28/25 7:58 PM, olcott wrote:
    On 7/28/2025 6:49 PM, Richard Damon wrote:
    On 7/28/25 7:20 PM, olcott wrote:
    On 7/28/2025 5:57 PM, Richard Damon wrote:
    On 7/28/25 9:54 AM, olcott wrote:
    On 7/28/2025 8:21 AM, joes wrote:
    Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
    On 7/28/2025 2:30 AM, joes wrote:
    Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
    On 7/27/25 8:20 PM, olcott wrote:

    When DDD is emulated by HHH1 it need not emulate itself >>>>>>>>>>>>>>>>> at all.
    But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at the >>>>>>>>>>>>>>> exact same
    machine address.
    Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>> change DDD.
    HHH is never changed.

    It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>>> is reporting
    on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>>> halting DDD,
    and definitely not on HHH(DDD), itself.


    All halt deciders are required to predict the behavior
    of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>> "return" instruction final halt state.


    How is it a "correct prediction" if it sees something
    different than what that DDD does.


    What DDD does is keep calling HHH(DDD) in recursive
    simulation until HHH kills this whole process.

    But the behavior of the program continues past that (something >>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>> and then Halt.

    Your problem is you don't understand that the simulating HHH
    doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>> that defines what a correct simulation of it is.


    Remember, to have simulated that DDD, it must have include the >>>>>>>>>> code of the HHH that it was based on, which is the HHH that >>>>>>>>>> made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>

    We are not asking: Does DDD() halt.
    That is (as it turns out) an incorrect question.

    No, that is EXACTLY the question.

    I guess you are just admitting that you whole world is based on >>>>>>>> LYING about what things are supposed to be.


    Turing machines cannot directly report on the behavior
    of other Turing machines they can at best indirectly
    report on the behavior of Turing machines through the
    proxy of finite string machine descriptions such as ⟨M⟩.

    Right, and HHH was given the equivalenet of (M) by being given >>>>>>>> the code of *ALL* of DDD

    I guess you don't understand that fact, even though you CLAIM >>>>>>>> the input is the proper representation of DDD.


    Thus the behavior specified by the input finite string
    overrules and supersedes the behavior of the direct
    execution.

    No, it is DEFINED to be the behavior of the direct execution of >>>>>>>> the program it represent.


    *That has always been the fatal flaw of all of the proofs*

    No, your failure to follow the rules is what makes you just a liar. >>>>>>

    _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]

    When the above code is in the same memory space as HHH
    such that DDD calls HHH(DDD) and then HHH does emulate
    itself emulating DDD then this does specify recursive
    emulation.

    Anyone or anything that disagrees would be disagreeing
    with the definition of the x86 language.


    So, if HHH accesses that memory, it becomes part of the input.


    It becomes part of the input in the sense that the
    correct simulation of the input to HHH(DDD) is not
    the same as the correct simulation of the input to
    HHH1(DDD) because DDD only calls HHH(DDD) and does
    not call HHH1(DDD).

    DDD correctly simulated by HHH cannot possibly
    halt thus HHH(DDD)==0 is correct.

    DDD correctly simulated by HHH1 does halt thus
    HHH(DDD)==1 is correct.



    It either *IS* or it *ISN'T* there is no middle.


    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.



    Sure they do, when correctly simulated. What doens't happne is that the PARTIAL simulation (and thus not correct) of HHH can't reach that state.

    All you are doing is proving that you whole mental model is based on the incorrect concept of subjective truth.

    Sorry, but you need to use an objective measure.

    In any instance, there is just ONE HHH, with SPECIFIC behavior, and the
    DDD that uses that HHH.

    If that HHH aborts and returns 0, then DDD halts. PERIOD, proven and you
    have agreed to it, that the DIRECT EXECUTION of DDD halts.

    Since the question is about that direct execution. your HHH is just
    wrong, becuae you LIE about what its actual test is, apparently because
    you have no idea what the words actually mean.

    You have shown that the simulated HHH will reach a final state, and that
    the simulated DDD will reach a final state, just that the simulation
    isn't the PARTIAL one done by HHH.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Wed Jul 30 09:52:13 2025
    From Newsgroup: comp.ai.philosophy

    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*

    _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 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.

    https://github.com/plolcott/x86utm/blob/master/Halt7.c

    Failing to do that proves that you are wrong.
    Because we have been over this so many times I am
    convinced that you already know that you are wrong
    and are just trolling me.

    There is no stack unwinding when HHH sees DDD calls the
    same function with the same parameter twice in sequence.
    At this point HHH kills the whole DDD process including
    all recursive emulations.

    based on the wrong assumption that a
    finite recursion specifies non-halting.

    Halting is defined as reaching the "return" statement
    final halt state. It is not defined as stopping running
    for any reason otherwise both of these would be determined
    to be halting:

    void Infinite_Recursion()
    {
    Infinite_Recursion();
    return;
    }

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

    Because they stop running as soon as their process it killed.

    Then the simulating HHH does
    reach its own halt state when it reports non-halting.

    Yet neither the simulated DDD nor the simulated HHH
    can possibly reach their own final halt state

    The simulated HHH, that has a similar final halt state after it aborts,

    The simulated HHH cannot possibly abort because the directly
    executed HHH is always one whole recursive simulation ahead
    thus reaching its abort criteria first.

    After HHH sees that its simulated DDD is calling the same
    function with the same parameter twice in sequence it kills
    the whole simulated process. Even if it waited to see this
    35 times in sequence the next inner one would have only seen
    it 34 times, thus has not met its own abort criteria.

    does not reach it own final halt state, because the simulating HHH does
    not allow it to reach it by the premature abort done by the simulating HHH.

    You cannot prove that your use of the term "premature abort"
    is anything besides a misconception. *See above challenge*
    --
    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 olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Wed Jul 30 10:02:05 2025
    From Newsgroup: comp.ai.philosophy

    On 7/30/2025 5:59 AM, Richard Damon wrote:
    On 7/29/25 11:12 PM, olcott wrote:
    On 7/29/2025 8:51 PM, Richard Damon wrote:
    On 7/29/25 9:24 PM, olcott wrote:
    On 7/29/2025 5:37 PM, Richard Damon wrote:
    On 7/29/25 12:53 PM, olcott wrote:
    On 7/28/2025 8:56 PM, Richard Damon wrote:
    On 7/28/25 7:58 PM, olcott wrote:
    On 7/28/2025 6:49 PM, Richard Damon wrote:
    On 7/28/25 7:20 PM, olcott wrote:
    On 7/28/2025 5:57 PM, Richard Damon wrote:
    On 7/28/25 9:54 AM, olcott wrote:
    On 7/28/2025 8:21 AM, joes wrote:
    Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
    On 7/28/2025 2:30 AM, joes wrote:
    Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
    On 7/27/25 8:20 PM, olcott wrote:

    When DDD is emulated by HHH1 it need not emulate >>>>>>>>>>>>>>>>>> itself at all.
    But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at >>>>>>>>>>>>>>>> the exact same
    machine address.
    Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>>> change DDD.
    HHH is never changed.

    It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>>>> is reporting
    on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>>>> halting DDD,
    and definitely not on HHH(DDD), itself.


    All halt deciders are required to predict the behavior >>>>>>>>>>>> of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>>> "return" instruction final halt state.


    How is it a "correct prediction" if it sees something
    different than what that DDD does.


    What DDD does is keep calling HHH(DDD) in recursive
    simulation until HHH kills this whole process.

    But the behavior of the program continues past that (something >>>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>>> and then Halt.

    Your problem is you don't understand that the simulating HHH >>>>>>>>> doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>>> that defines what a correct simulation of it is.


    Remember, to have simulated that DDD, it must have include >>>>>>>>>>> the code of the HHH that it was based on, which is the HHH >>>>>>>>>>> that made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>>

    We are not asking: Does DDD() halt.
    That is (as it turns out) an incorrect question.

    No, that is EXACTLY the question.

    I guess you are just admitting that you whole world is based on >>>>>>>>> LYING about what things are supposed to be.


    Turing machines cannot directly report on the behavior
    of other Turing machines they can at best indirectly
    report on the behavior of Turing machines through the
    proxy of finite string machine descriptions such as ⟨M⟩. >>>>>>>>>
    Right, and HHH was given the equivalenet of (M) by being given >>>>>>>>> the code of *ALL* of DDD

    I guess you don't understand that fact, even though you CLAIM >>>>>>>>> the input is the proper representation of DDD.


    Thus the behavior specified by the input finite string
    overrules and supersedes the behavior of the direct
    execution.

    No, it is DEFINED to be the behavior of the direct execution of >>>>>>>>> the program it represent.


    *That has always been the fatal flaw of all of the proofs*

    No, your failure to follow the rules is what makes you just a liar. >>>>>>>

    _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]

    When the above code is in the same memory space as HHH
    such that DDD calls HHH(DDD) and then HHH does emulate
    itself emulating DDD then this does specify recursive
    emulation.

    Anyone or anything that disagrees would be disagreeing
    with the definition of the x86 language.


    So, if HHH accesses that memory, it becomes part of the input.


    It becomes part of the input in the sense that the
    correct simulation of the input to HHH(DDD) is not
    the same as the correct simulation of the input to
    HHH1(DDD) because DDD only calls HHH(DDD) and does
    not call HHH1(DDD).

    DDD correctly simulated by HHH cannot possibly
    halt thus HHH(DDD)==0 is correct.

    DDD correctly simulated by HHH1 does halt thus
    HHH(DDD)==1 is correct.



    It either *IS* or it *ISN'T* there is no middle.


    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.



    Sure they do, when correctly simulated. What doens't happne is that the PARTIAL simulation (and thus not correct) of HHH can't reach that state.


    _DDD()
    [0000219e] 55 push ebp
    [0000219f] 8bec mov ebp,esp
    [000021a1] 689e210000 push 0000219e
    [000021a6] e843f4ffff call 000015ee
    [000021ab] 83c404 add esp,+04
    [000021ae] 5d pop ebp
    [000021af] c3 ret
    Size in bytes:(0018) [000021af]

    We have been over this too many times. If DDD was
    incorrectly emulated by HHH then you could show
    the exact x86 instruction of DDD that was emulated
    incorrectly when DDD is emulated by HHH or when
    DDD is emulated by the emulated HHH.

    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
    New slave_stack at:103916

    Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000219e][0011390e][00113912] 55 push ebp [0000219f][0011390e][00113912] 8bec mov ebp,esp [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
    New slave_stack at:14e33e
    [0000219e][0015e336][0015e33a] 55 push ebp [0000219f][0015e336][0015e33a] 8bec mov ebp,esp [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH

    That you never made any attempt at an actual rebuttal
    seems to prove that you know you are wrong.
    --
    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 olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Wed Jul 30 11:02:34 2025
    From Newsgroup: comp.ai.philosophy

    On 7/30/2025 10:58 AM, wij wrote:
    On Wed, 2025-07-30 at 10:43 -0500, olcott wrote:
    On 7/30/2025 10:23 AM, joes wrote:
    Am Wed, 30 Jul 2025 10:02:05 -0500 schrieb olcott:
    On 7/30/2025 5:59 AM, Richard Damon wrote:
    On 7/29/25 11:12 PM, olcott wrote:

    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.

    Sure they do, when correctly simulated. What doens't happne is that the >>>>> PARTIAL simulation (and thus not correct) of HHH can't reach that
    state.

    We have been over this too many times. If DDD was incorrectly emulated >>>> by HHH then you could show the exact x86 instruction of DDD that was
    emulated incorrectly when DDD is emulated by HHH or when DDD is emulated >>>> by the emulated HHH.

    Yeah, we have. The second call to HHH is not simulated.


    I proved that the emulated HHH does emulate DDD correctly
    and you simply ignored this proof.

    You are shown not qualified to use 'prove' word and 'correct'. You have no valid base.


    That you cannot understand the sequence of steps that proves
    that DDD is correctly emulated by HHH and DDD is correctly
    emulated by an emulated HHH is not any actual rebuttal at all.

    _DDD()
    [0000219e] 55 push ebp
    [0000219f] 8bec mov ebp,esp
    [000021a1] 689e210000 push 0000219e
    [000021a6] e843f4ffff call 000015ee
    [000021ab] 83c404 add esp,+04
    [000021ae] 5d pop ebp
    [000021af] c3 ret
    Size in bytes:(0018) [000021af]

    _main()
    [000021be] 55 push ebp
    [000021bf] 8bec mov ebp,esp
    [000021c1] 689e210000 push 0000219e
    [000021c6] e823f4ffff call 000015ee
    [000021cb] 83c404 add esp,+04
    [000021ce] 50 push eax
    [000021cf] 685f070000 push 0000075f
    [000021d4] e8a5e5ffff call 0000077e
    [000021d9] 83c408 add esp,+08
    [000021dc] 33c0 xor eax,eax
    [000021de] 5d pop ebp
    [000021df] c3 ret
    Size in bytes:(0034) [000021df]

    machine stack stack machine assembly
    address address data code language
    ======== ======== ======== ========== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
    New slave_stack at:103916

    Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000219e][0011390e][00113912] 55 push ebp [0000219f][0011390e][00113912] 8bec mov ebp,esp [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
    New slave_stack at:14e33e
    [0000219e][0015e336][0015e33a] 55 push ebp [0000219f][0015e336][0015e33a] 8bec mov ebp,esp [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH
    --
    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 Wed Jul 30 19:58:05 2025
    From Newsgroup: comp.ai.philosophy

    On 7/30/25 11:02 AM, olcott wrote:
    On 7/30/2025 5:59 AM, Richard Damon wrote:
    On 7/29/25 11:12 PM, olcott wrote:
    On 7/29/2025 8:51 PM, Richard Damon wrote:
    On 7/29/25 9:24 PM, olcott wrote:
    On 7/29/2025 5:37 PM, Richard Damon wrote:
    On 7/29/25 12:53 PM, olcott wrote:
    On 7/28/2025 8:56 PM, Richard Damon wrote:
    On 7/28/25 7:58 PM, olcott wrote:
    On 7/28/2025 6:49 PM, Richard Damon wrote:
    On 7/28/25 7:20 PM, olcott wrote:
    On 7/28/2025 5:57 PM, Richard Damon wrote:
    On 7/28/25 9:54 AM, olcott wrote:
    On 7/28/2025 8:21 AM, joes wrote:
    Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/28/2025 2:30 AM, joes wrote:
    Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
    On 7/27/25 8:20 PM, olcott wrote:

    When DDD is emulated by HHH1 it need not emulate >>>>>>>>>>>>>>>>>>> itself at all.
    But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at >>>>>>>>>>>>>>>>> the exact same
    machine address.
    Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>>>> change DDD.
    HHH is never changed.

    It is changed in the hypothetical unaborted simulation. >>>>>>>>>>>>>> HHH is reporting
    on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on >>>>>>>>>>>>>> the halting DDD,
    and definitely not on HHH(DDD), itself.


    All halt deciders are required to predict the behavior >>>>>>>>>>>>> of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>>>> "return" instruction final halt state.


    How is it a "correct prediction" if it sees something >>>>>>>>>>>> different than what that DDD does.


    What DDD does is keep calling HHH(DDD) in recursive
    simulation until HHH kills this whole process.

    But the behavior of the program continues past that (something >>>>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>>>> and then Halt.

    Your problem is you don't understand that the simulating HHH >>>>>>>>>> doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>>>> that defines what a correct simulation of it is.


    Remember, to have simulated that DDD, it must have include >>>>>>>>>>>> the code of the HHH that it was based on, which is the HHH >>>>>>>>>>>> that made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>>>

    We are not asking: Does DDD() halt.
    That is (as it turns out) an incorrect question.

    No, that is EXACTLY the question.

    I guess you are just admitting that you whole world is based >>>>>>>>>> on LYING about what things are supposed to be.


    Turing machines cannot directly report on the behavior
    of other Turing machines they can at best indirectly
    report on the behavior of Turing machines through the
    proxy of finite string machine descriptions such as ⟨M⟩. >>>>>>>>>>
    Right, and HHH was given the equivalenet of (M) by being given >>>>>>>>>> the code of *ALL* of DDD

    I guess you don't understand that fact, even though you CLAIM >>>>>>>>>> the input is the proper representation of DDD.


    Thus the behavior specified by the input finite string
    overrules and supersedes the behavior of the direct
    execution.

    No, it is DEFINED to be the behavior of the direct execution >>>>>>>>>> of the program it represent.


    *That has always been the fatal flaw of all of the proofs*

    No, your failure to follow the rules is what makes you just a liar. >>>>>>>>

    _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]

    When the above code is in the same memory space as HHH
    such that DDD calls HHH(DDD) and then HHH does emulate
    itself emulating DDD then this does specify recursive
    emulation.

    Anyone or anything that disagrees would be disagreeing
    with the definition of the x86 language.


    So, if HHH accesses that memory, it becomes part of the input.


    It becomes part of the input in the sense that the
    correct simulation of the input to HHH(DDD) is not
    the same as the correct simulation of the input to
    HHH1(DDD) because DDD only calls HHH(DDD) and does
    not call HHH1(DDD).

    DDD correctly simulated by HHH cannot possibly
    halt thus HHH(DDD)==0 is correct.

    DDD correctly simulated by HHH1 does halt thus
    HHH(DDD)==1 is correct.



    It either *IS* or it *ISN'T* there is no middle.


    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.



    Sure they do, when correctly simulated. What doens't happne is that
    the PARTIAL simulation (and thus not correct) of HHH can't reach that
    state.


    _DDD()
    [0000219e] 55             push ebp
    [0000219f] 8bec           mov ebp,esp
    [000021a1] 689e210000     push 0000219e
    [000021a6] e843f4ffff     call 000015ee
    [000021ab] 83c404         add esp,+04
    [000021ae] 5d             pop ebp
    [000021af] c3             ret
    Size in bytes:(0018) [000021af]

    cant' be the full input as not simuatable.


    We have been over this too many times. If DDD was
    incorrectly emulated by HHH then you could show
    the exact x86 instruction of DDD that was emulated
    incorrectly when DDD is emulated by HHH or when
    DDD is emulated by the emulated HHH.

    The Call HHH instruction below.

    Or the last instruction it simulates (which is also a call HHH
    instruction) in the full trace.

    Since the CORRECT simulation of a call instruction includes the
    execution of the instruction refenced by the call instruction.




     machine   stack     stack     machine        assembly
     address   address   data      code           language
     ========  ========  ========  ========== ============= [000021be][00103872][00000000] 55         push ebp [000021bf][00103872][00000000] 8bec       mov ebp,esp [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
    New slave_stack at:103916

    Not a correct simulation of the call HHH instruction.


    Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e [0000219e][0011390e][00113912] 55         push ebp [0000219f][0011390e][00113912] 8bec       mov ebp,esp [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
    New slave_stack at:14e33e
    [0000219e][0015e336][0015e33a] 55         push ebp [0000219f][0015e336][0015e33a] 8bec       mov ebp,esp [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH

    That you never made any attempt at an actual rebuttal
    seems to prove that you know you are wrong.


    Sure I have, many times.

    YOu are just too stupid to understand what I say, because you have
    blinded yourself by you lies.

    Darkness has enveloped your mind, and you have doomed yourself to
    never-ending darkness.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Wed Jul 30 19:42:12 2025
    From Newsgroup: comp.ai.philosophy

    On 7/30/2025 6:58 PM, Richard Damon wrote:
    On 7/30/25 11:02 AM, olcott wrote:
    _DDD()
    [0000219e] 55             push ebp
    [0000219f] 8bec           mov ebp,esp
    [000021a1] 689e210000     push 0000219e
    [000021a6] e843f4ffff     call 000015ee
    [000021ab] 83c404         add esp,+04
    [000021ae] 5d             pop ebp
    [000021af] c3             ret
    Size in bytes:(0018) [000021af]

    cant' be the full input as not simuatable.


    We have been over this too many times. If DDD was
    incorrectly emulated by HHH then you could show
    the exact x86 instruction of DDD that was emulated
    incorrectly when DDD is emulated by HHH or when
    DDD is emulated by the emulated HHH.

    The Call HHH instruction below.

    Or the last instruction it simulates (which is also a call HHH
    instruction) in the full trace.

    Since the CORRECT simulation of a call instruction includes the
    execution of the instruction referenced by the call instruction.




      machine   stack     stack     machine        assembly >>   address   address   data      code           language >>   ========  ========  ========  ========== =============
    [000021be][00103872][00000000] 55         push ebp
    [000021bf][00103872][00000000] 8bec       mov ebp,esp
    [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
    [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
    New slave_stack at:103916

    Not a correct simulation of the call HHH instruction.


    Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e
    [0000219e][0011390e][00113912] 55         push ebp
    [0000219f][0011390e][00113912] 8bec       mov ebp,esp
    [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
    [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
    New slave_stack at:14e33e
    [0000219e][0015e336][0015e33a] 55         push ebp
    [0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
    [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
    [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH


    The above proves that HHH does emulate itself emulating
    DDD correctly in that the emulated HHH does emulate DDD
    correctly.

    It also shows the repeating pattern that DDD correctly
    emulated by DDD derives.

    Without even having an implemented HHH we can still
    see that DDD emulated by an emulated HHH would produce
    this same same repeating pattern.
    --
    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 Wed Jul 30 22:16:45 2025
    From Newsgroup: comp.ai.philosophy

    On 7/30/25 8:42 PM, olcott wrote:
    On 7/30/2025 6:58 PM, Richard Damon wrote:
    On 7/30/25 11:02 AM, olcott wrote:
    _DDD()
    [0000219e] 55             push ebp
    [0000219f] 8bec           mov ebp,esp
    [000021a1] 689e210000     push 0000219e
    [000021a6] e843f4ffff     call 000015ee
    [000021ab] 83c404         add esp,+04
    [000021ae] 5d             pop ebp
    [000021af] c3             ret
    Size in bytes:(0018) [000021af]

    cant' be the full input as not simuatable.


    We have been over this too many times. If DDD was
    incorrectly emulated by HHH then you could show
    the exact x86 instruction of DDD that was emulated
    incorrectly when DDD is emulated by HHH or when
    DDD is emulated by the emulated HHH.

    The Call HHH instruction below.

    Or the last instruction it simulates (which is also a call HHH
    instruction) in the full trace.

    Since the CORRECT simulation of a call instruction includes the
    execution of the instruction referenced by the call instruction.




      machine   stack     stack     machine        assembly >>>   address   address   data      code           language
      ========  ========  ========  ========== =============
    [000021be][00103872][00000000] 55         push ebp
    [000021bf][00103872][00000000] 8bec       mov ebp,esp
    [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
    [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
    New slave_stack at:103916

    Not a correct simulation of the call HHH instruction.


    Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e >>> [0000219e][0011390e][00113912] 55         push ebp
    [0000219f][0011390e][00113912] 8bec       mov ebp,esp
    [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
    [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
    New slave_stack at:14e33e
    [0000219e][0015e336][0015e33a] 55         push ebp
    [0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
    [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
    [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH


    The above proves that HHH does emulate itself emulating
    DDD correctly in that the emulated HHH does emulate DDD
    correctly.

    No, because you don't show the simulation of the code of HHH.

    I guess you don't know what that means.


    It also shows the repeating pattern that DDD correctly
    emulated by DDD derives.

    But that isn't what actually happens. the second copy doesn't actually
    happen in the actual simulation of the input.


    Without even having an implemented HHH we can still
    see that DDD emulated by an emulated HHH would produce
    this same same repeating pattern.


    But if HHH isn't implements, you can't HAVE DDD as a valid input.

    All you are doing is proving you are just lying about what you are doing.

    You are just proving that your whold argument is based on category
    errors and lies.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Thu Jul 31 11:26:07 2025
    From Newsgroup: comp.ai.philosophy

    On 7/30/2025 9:16 PM, Richard Damon wrote:
    On 7/30/25 8:42 PM, olcott wrote:
    On 7/30/2025 6:58 PM, Richard Damon wrote:
    On 7/30/25 11:02 AM, olcott wrote:
    _DDD()
    [0000219e] 55             push ebp
    [0000219f] 8bec           mov ebp,esp
    [000021a1] 689e210000     push 0000219e
    [000021a6] e843f4ffff     call 000015ee
    [000021ab] 83c404         add esp,+04
    [000021ae] 5d             pop ebp
    [000021af] c3             ret
    Size in bytes:(0018) [000021af]

    cant' be the full input as not simuatable.


    We have been over this too many times. If DDD was
    incorrectly emulated by HHH then you could show
    the exact x86 instruction of DDD that was emulated
    incorrectly when DDD is emulated by HHH or when
    DDD is emulated by the emulated HHH.

    The Call HHH instruction below.

    Or the last instruction it simulates (which is also a call HHH
    instruction) in the full trace.

    Since the CORRECT simulation of a call instruction includes the
    execution of the instruction referenced by the call instruction.




      machine   stack     stack     machine        assembly >>>>   address   address   data      code           language
      ========  ========  ========  ========== =============
    [000021be][00103872][00000000] 55         push ebp
    [000021bf][00103872][00000000] 8bec       mov ebp,esp
    [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
    [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
    New slave_stack at:103916

    Not a correct simulation of the call HHH instruction.


    Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e >>>> [0000219e][0011390e][00113912] 55         push ebp
    [0000219f][0011390e][00113912] 8bec       mov ebp,esp
    [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
    [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
    New slave_stack at:14e33e
    [0000219e][0015e336][0015e33a] 55         push ebp
    [0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
    [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
    [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH


    The above proves that HHH does emulate itself emulating
    DDD correctly in that the emulated HHH does emulate DDD
    correctly.

    No, because you don't show the simulation of the code of HHH.


    Mixing the above 8 instructions in with another 176
    pages of instructions does not help understanding
    things.

    https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

    We can know that HHH did correctly emulate itself
    emulating DDD because this emulated HHH does derive
    the correct first four instructions of DDD.
    I guess you don't know what that means.


    It also shows the repeating pattern that DDD correctly
    emulated by DDD derives.

    But that isn't what actually happens. the second copy doesn't actually happen in the actual simulation of the input.


    Counter-factual and this proves that it is counter-factual https://liarparadox.org/HHH(DDD)_Full_Trace.pdf


    Without even having an implemented HHH we can still
    see that DDD emulated by an emulated HHH would produce
    this same same repeating pattern.


    But if HHH isn't implements, you can't HAVE DDD as a valid input.

    HHH is implemented yet too difficult for you to
    understand so we verify that DDD does emulate
    itself emulating DDD in that its emulated DDD
    does emulate the first four instructions of DDD
    as shown above.


    All you are doing is proving you are just lying about what you are doing.


    That you call me a liar could get you condemned to actual Hell.
    Revelations 21:8
    ...all liars, their lot shall be in the lake that burns
    with fire and sulphur, which is the second death.”

    You are just proving that your whold argument is based on category
    errors and lies.

    That you keep changing the words that I say to make your
    rebuttal easier is the strawman deception can could get you
    condemned to actual Hell.
    --
    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 Thu Jul 31 19:34:41 2025
    From Newsgroup: comp.ai.philosophy

    On 7/31/25 12:26 PM, olcott wrote:
    On 7/30/2025 9:16 PM, Richard Damon wrote:
    On 7/30/25 8:42 PM, olcott wrote:
    On 7/30/2025 6:58 PM, Richard Damon wrote:
    On 7/30/25 11:02 AM, olcott wrote:
    _DDD()
    [0000219e] 55             push ebp
    [0000219f] 8bec           mov ebp,esp
    [000021a1] 689e210000     push 0000219e
    [000021a6] e843f4ffff     call 000015ee
    [000021ab] 83c404         add esp,+04
    [000021ae] 5d             pop ebp
    [000021af] c3             ret
    Size in bytes:(0018) [000021af]

    cant' be the full input as not simuatable.


    We have been over this too many times. If DDD was
    incorrectly emulated by HHH then you could show
    the exact x86 instruction of DDD that was emulated
    incorrectly when DDD is emulated by HHH or when
    DDD is emulated by the emulated HHH.

    The Call HHH instruction below.

    Or the last instruction it simulates (which is also a call HHH
    instruction) in the full trace.

    Since the CORRECT simulation of a call instruction includes the
    execution of the instruction referenced by the call instruction.




      machine   stack     stack     machine        assembly
      address   address   data      code           language
      ========  ========  ========  ========== =============
    [000021be][00103872][00000000] 55         push ebp
    [000021bf][00103872][00000000] 8bec       mov ebp,esp
    [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
    [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
    New slave_stack at:103916

    Not a correct simulation of the call HHH instruction.


    Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e >>>>> [0000219e][0011390e][00113912] 55         push ebp
    [0000219f][0011390e][00113912] 8bec       mov ebp,esp
    [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
    [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
    New slave_stack at:14e33e
    [0000219e][0015e336][0015e33a] 55         push ebp
    [0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
    [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
    [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH


    The above proves that HHH does emulate itself emulating
    DDD correctly in that the emulated HHH does emulate DDD
    correctly.

    No, because you don't show the simulation of the code of HHH.


    Mixing the above 8 instructions in with another 176
    pages of instructions does not help understanding
    things.

    And FAILING to do it is just a lie.


    https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

    Which, as has been pointed out, NOT the trace generated by HHH
    simulating DDD, as it begins at main, which HHH NEVER simulates.

    Thus, you are showing you don't know what you are talking about.

    Perhaps if you removed that extraneous level of simulation into one
    trace, you would get likely a 3-10 page trace of what HHH actually sees
    in its simulation, which could be compared to the first pages of that
    176 page simulation of main (which looks just like DDD except for the
    address it is at) with HHHs simulation, and see that they EXACTLY match,
    and since the 176 pages reach a final state, the 3-10 pages can't have a non-halting pattern in them.



    We can know that HHH did correctly emulate itself
    emulating DDD because this emulated HHH does derive
    the correct first four instructions of DDD.

    Nope, that ignores critical details of HHHs behavior, thus showing that
    you are just trying to hide your lies.

    Note, the extra layer that you show is just a Red Herring,

    I guess you don't know what that means.


    It also shows the repeating pattern that DDD correctly
    emulated by DDD derives.

    But that isn't what actually happens. the second copy doesn't actually
    happen in the actual simulation of the input.


    Counter-factual and this proves that it is counter-factual https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

    Nope, as explained above, you just lie about what that is.

    Note, Your "trace" results are merged from every level of the
    simulation, and thus isn't a single correct trace of anybody, but the
    correct trace CAN be worked out with a bit of work.

    That shows that the code of Main/DDD calling HHH(DDD) will eventually
    return to a final state.

    The SImulaiton that HHH does aborts part way through that simulation,
    and thus fails to be the correct simulaition, as that is required to be complete.

    Thus, all your claims are just shown to be a lie.

    Until you actually point out a specific errot in those statements, you
    are just proving that you are nothing but a pathological liar that
    doesn't actually care about be correct.



    Without even having an implemented HHH we can still
    see that DDD emulated by an emulated HHH would produce
    this same same repeating pattern.


    But if HHH isn't implements, you can't HAVE DDD as a valid input.

    HHH is implemented yet too difficult for you to
    understand so we verify that DDD does emulate
    itself emulating DDD in that its emulated DDD
    does emulate the first four instructions of DDD
    as shown above.

    You can't HAVE DDD until you implement HHH.

    Sorry, you are just proving you don't understand the basics of what you
    are talking about, and everything you say is based on LIES.



    All you are doing is proving you are just lying about what you are doing.


    That you call me a liar could get you condemned to actual Hell.
    Revelations 21:8
    ...all liars, their lot shall be in the lake that burns
    with fire and sulphur, which is the second death.”

    Since my statements are NOT lies, I don't need to worry about that. I
    can reference the actual definitios that support what I say.

    Since you CAN'T, because you chose to not know the meanings, but are
    just guessing, you have chose the way of the ignorant liar, who is
    doomed to that fate.

    Are you really that sure of the stuff you just made up to bet on that?


    You are just proving that your whold argument is based on category
    errors and lies.

    That you keep changing the words that I say to make your
    rebuttal easier is the strawman deception can could get you
    condemned to actual Hell.


    No, I use the words you use in there actual meaning.

    I point out that YOU have changed the definition of the problem, and
    point out that BY THE DEFINITION you are wrong.

    That you keep on insisting the problem means something it doesn't just
    make you a liar.

    That you can't understand those meanings just makes you stupid.

    Your ignorance and inability to understand statements, doesn't make the
    wrong, only your denial of them is wrong.

    Sorry, it look like you have booked your ticket to that lake of fire.

    You might have made advanced reservations years ago when you claimed to
    be God, as that is also is one of the bigger qualifications for that trip.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Thu Jul 31 18:54:46 2025
    From Newsgroup: comp.ai.philosophy

    On 7/31/2025 6:34 PM, Richard Damon wrote:
    On 7/31/25 12:26 PM, olcott wrote:
    On 7/30/2025 9:16 PM, Richard Damon wrote:
    On 7/30/25 8:42 PM, olcott wrote:
    On 7/30/2025 6:58 PM, Richard Damon wrote:
    On 7/30/25 11:02 AM, olcott wrote:
    _DDD()
    [0000219e] 55             push ebp
    [0000219f] 8bec           mov ebp,esp
    [000021a1] 689e210000     push 0000219e
    [000021a6] e843f4ffff     call 000015ee
    [000021ab] 83c404         add esp,+04
    [000021ae] 5d             pop ebp
    [000021af] c3             ret
    Size in bytes:(0018) [000021af]

    cant' be the full input as not simuatable.


    We have been over this too many times. If DDD was
    incorrectly emulated by HHH then you could show
    the exact x86 instruction of DDD that was emulated
    incorrectly when DDD is emulated by HHH or when
    DDD is emulated by the emulated HHH.

    The Call HHH instruction below.

    Or the last instruction it simulates (which is also a call HHH
    instruction) in the full trace.

    Since the CORRECT simulation of a call instruction includes the
    execution of the instruction referenced by the call instruction.




      machine   stack     stack     machine        assembly
      address   address   data      code           language
      ========  ========  ========  ========== =============
    [000021be][00103872][00000000] 55         push ebp
    [000021bf][00103872][00000000] 8bec       mov ebp,esp
    [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD >>>>>> [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH >>>>>> New slave_stack at:103916

    Not a correct simulation of the call HHH instruction.


    Begin Local Halt Decider Simulation   Execution Trace Stored
    at:11391e
    [0000219e][0011390e][00113912] 55         push ebp
    [0000219f][0011390e][00113912] 8bec       mov ebp,esp
    [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD >>>>>> [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH >>>>>> New slave_stack at:14e33e
    [0000219e][0015e336][0015e33a] 55         push ebp
    [0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
    [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD >>>>>> [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH >>>>>>

    The above proves that HHH does emulate itself emulating
    DDD correctly in that the emulated HHH does emulate DDD
    correctly.

    No, because you don't show the simulation of the code of HHH.


    Mixing the above 8 instructions in with another 176
    pages of instructions does not help understanding
    things.

    And FAILING to do it is just a lie.


    https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

    Which, as has been pointed out, NOT the trace generated by HHH
    simulating DDD, as it begins at main, which HHH NEVER simulates.


    HHH simulates DDD then simulates a different instance
    of itself simulating a different instance of DDD which
    calls another different instance of HHH(DDD)...
    --
    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 Thu Jul 31 20:16:01 2025
    From Newsgroup: comp.ai.philosophy

    On 7/31/25 7:54 PM, olcott wrote:
    On 7/31/2025 6:34 PM, Richard Damon wrote:
    On 7/31/25 12:26 PM, olcott wrote:
    On 7/30/2025 9:16 PM, Richard Damon wrote:
    On 7/30/25 8:42 PM, olcott wrote:
    On 7/30/2025 6:58 PM, Richard Damon wrote:
    On 7/30/25 11:02 AM, olcott wrote:
    _DDD()
    [0000219e] 55             push ebp
    [0000219f] 8bec           mov ebp,esp
    [000021a1] 689e210000     push 0000219e
    [000021a6] e843f4ffff     call 000015ee
    [000021ab] 83c404         add esp,+04
    [000021ae] 5d             pop ebp
    [000021af] c3             ret
    Size in bytes:(0018) [000021af]

    cant' be the full input as not simuatable.


    We have been over this too many times. If DDD was
    incorrectly emulated by HHH then you could show
    the exact x86 instruction of DDD that was emulated
    incorrectly when DDD is emulated by HHH or when
    DDD is emulated by the emulated HHH.

    The Call HHH instruction below.

    Or the last instruction it simulates (which is also a call HHH
    instruction) in the full trace.

    Since the CORRECT simulation of a call instruction includes the
    execution of the instruction referenced by the call instruction.




      machine   stack     stack     machine        assembly
      address   address   data      code           language
      ========  ========  ========  ========== =============
    [000021be][00103872][00000000] 55         push ebp
    [000021bf][00103872][00000000] 8bec       mov ebp,esp
    [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD >>>>>>> [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH >>>>>>> New slave_stack at:103916

    Not a correct simulation of the call HHH instruction.


    Begin Local Halt Decider Simulation   Execution Trace Stored
    at:11391e
    [0000219e][0011390e][00113912] 55         push ebp
    [0000219f][0011390e][00113912] 8bec       mov ebp,esp
    [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD >>>>>>> [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH >>>>>>> New slave_stack at:14e33e
    [0000219e][0015e336][0015e33a] 55         push ebp
    [0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
    [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD >>>>>>> [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH >>>>>>>

    The above proves that HHH does emulate itself emulating
    DDD correctly in that the emulated HHH does emulate DDD
    correctly.

    No, because you don't show the simulation of the code of HHH.


    Mixing the above 8 instructions in with another 176
    pages of instructions does not help understanding
    things.

    And FAILING to do it is just a lie.


    https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

    Which, as has been pointed out, NOT the trace generated by HHH
    simulating DDD, as it begins at main, which HHH NEVER simulates.


    HHH simulates DDD then simulates a different instance
    of itself simulating a different instance of DDD which
    calls another different instance of HHH(DDD)...


    Nope. That isn't what you code, or your simulation of it shows.

    I guess you forgot how you defined HHH.

    Your HHH is defined to abort its simulation, at a specific point.

    Anything else is just you LYING about HHH.

    Looks like you are booking your trip to the lake.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Fred. Zwarts@F.Zwarts@HetNet.nl to comp.theory,sci.logic,comp.ai.philosophy on Fri Aug 1 11:00:17 2025
    From Newsgroup: comp.ai.philosophy

    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.


    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.
    Your huge mistake is you claim that if HHH cannot be corrected, then HHH
    must be correct.
    If something cannot be corrected, that does not prove that it is correct.
    Using simulation is just the incorrect tool for this problem. A
    simulator must fail when it tries to simulate itself, because it cannot possible simulate itself correctly up to the end.
    We know that for a larger number HHH will be able to correctly analyse
    this input, but then we can construct another DDD, based on the new HHH,
    for which HHH will fail again.
    This only proves the correctness of the halting theorem. No decider
    exists that correctly decides about the halting behaviour of all
    possible inputs.


    https://github.com/plolcott/x86utm/blob/master/Halt7.c

    Failing to do that proves that you are wrong.

    As usual incorrect claims without evidence.

    Because we have been over this so many times I am
    convinced that you already know that you are wrong
    and are just trolling me.

    You may close your eyes again and pretend that the errors in your logic
    do not eist. Very childish.


    There is no stack unwinding when HHH sees DDD calls the
    same function with the same parameter twice in sequence.
    At this point HHH kills the whole DDD process including
    all recursive emulations.

    In this case the parameter of DDD is irrelevant. HHH should take into
    account the state changes in the simulated HHH, which influence its conditional branch instructions.


    based on the wrong assumption that a finite recursion specifies non-
    halting.

    Halting is defined as reaching the "return" statement
    final halt state. It is not defined as stopping running
    for any reason otherwise both of these would be determined
    to be halting:

    void Infinite_Recursion()
    {
      Infinite_Recursion();
      return;
    }

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


    More relevant is:

    void Finite_Recursion () {
    int N = 5;
    if (N > 0) Finite_Recursion ();
    printf ("Olcott thinks this is never printed.\n");
    }

    Even if this when this function is called twice in succession without
    any changed parameter, there is no infinite recursion.
    The same happens inside HHH, where a count is maintained of calls to
    DDD. This count influences the conditional branch instructions within HHH.


    Because they stop running as soon as their process it killed.

    Irrelevant.


    Then the simulating HHH does reach its own halt state when it reports
    non-halting.

    Yet neither the simulated DDD nor the simulated HHH
    can possibly reach their own final halt state

    Only because the simulating HHH prevents them to do so by the premature
    abort. Without the premature abort, they do reach their final halt
    state, as proven by other world-class simulators.


    The simulated HHH, that has a similar final halt state after it aborts,

    The simulated HHH cannot possibly abort because the directly
    executed HHH is always one whole recursive simulation ahead
    thus reaching its abort criteria first.

    Indeed, the simulating HHH prevents the simulated HHH to reach its final
    halt state.


    After HHH sees that its simulated DDD is calling the same
    function with the same parameter twice in sequence it kills
    the whole simulated process. Even if it waited to see this
    35 times in sequence the next inner one would have only seen
    it 34 times, thus has not met its own abort criteria.

    Counter factual. When HHH would wait 3 times, it would see that the
    simulated HHH aborts after 2 cycles for this input with a HHH that
    aborts after 2 cycles.
    But you are cheating by also changing the input, so that now it requires
    36 cycles.


    does not reach it own final halt state, because the simulating HHH
    does not allow it to reach it by the premature abort done by the
    simulating HHH.

    You cannot prove that your use of the term "premature abort"
    is anything besides a misconception. *See above challenge*

    I have proven it, but you close your eyes for it and claim it does not
    exist.



    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Fri Aug 1 10:12:35 2025
    From Newsgroup: comp.ai.philosophy

    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.

    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.


    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.
    --
    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 Fri Aug 1 11:20:24 2025
    From Newsgroup: comp.ai.philosophy

    On 8/1/25 11:12 AM, olcott wrote:
    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.

    But since you HHH does abort the simulation of its input, that is an
    irrelvent fact.

    Just like making a proof that begins with, if pi was 3.


    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.


    I guess you are just admitting that your repesentation system is incorrect.

    THe "behavior of their input" is DEFINED to be the behavior of the
    program the input represents, so if it isn't, that just means you
    started with a bad representation.

    Maybe you need to learn to do thing right, and not just assume you can
    guess about things.

    All you are doing is proving your stupidity.


    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.



    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Fri Aug 1 10:44:59 2025
    From Newsgroup: comp.ai.philosophy

    On 8/1/2025 10:26 AM, joes wrote:
    Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:

    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.

    Yes, after 12 instructions of DDD only or just before the third
    recursive simulation.

    Everyone keeps dishonestly changing my words from
    (a) DDD correctly simulated by HHH (can't possibly halt)
    (b) The directly executed DDD (that halts).

    Turing machine deciders do not have directly executed
    Turing machines in their domain. They only have finite
    string machine description in their domain.

    This means that when the behavior specified by the correct
    simulation of the input disagrees with the behavior of the
    direct execution of DDD() it is the behavior specified by
    the input that overrules and supersedes.
    --
    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 Fri Aug 1 12:00:02 2025
    From Newsgroup: comp.ai.philosophy

    On 8/1/25 11:44 AM, olcott wrote:
    On 8/1/2025 10:26 AM, joes wrote:
    Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:

    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.

    Yes, after 12 instructions of DDD only or just before the third
    recursive simulation.

    Everyone keeps dishonestly changing my words from
    (a) DDD correctly simulated by HHH (can't possibly halt)

    No, it is that THIS HHH doesn't correctly simulate THIS DDD,

    And your Hypothetical HHH that does the correct simulation, isn't doing
    it to THIS DDD, but a different hypothetical one built on it.

    You just don't understand (or just blantently lie) what a program is, or
    why the input needs to be one.

    (b) The directly executed DDD (that halts).

    Because that is the actual criteria that Halt Deciders MUST use.

    Anything else is just a strawman.


    Turing machine deciders do not have directly executed
    Turing machines in their domain. They only have finite
    string machine description in their domain.

    Sure they do, via the concept of REPRESENTATION.

    I guess you don't think you can use your computer to watch viedo (lke
    the kiddie porn you were caught with)or listen to audio, or process
    text, since none of those is actually 0s and 1s like the physical
    computers process


    This means that when the behavior specified by the correct
    simulation of the input disagrees with the behavior of the
    direct execution of DDD() it is the behavior specified by
    the input that overrules and supersedes.


    Nope, just shows you are just a stupid liar that doesn't understand what
    he is talking about.

    The CORRECT SIMULATION of the CORRECT REPRESENTATION of a program will
    exactly match the behavior of that program when run.

    That is the behavior that that input represents to a Halt Decider.

    So, you are just proving your self to be a stupid liar.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Fri Aug 1 11:51:13 2025
    From Newsgroup: comp.ai.philosophy

    On 8/1/2025 11:00 AM, Richard Damon wrote:
    On 8/1/25 11:44 AM, olcott wrote:
    On 8/1/2025 10:26 AM, joes wrote:
    Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:

    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.

    Yes, after 12 instructions of DDD only or just before the third
    recursive simulation.

    Everyone keeps dishonestly changing my words from
    (a) DDD correctly simulated by HHH (can't possibly halt)

    No, it is that THIS HHH doesn't correctly simulate THIS DDD,


    The outermost directly executed HHH does correctly
    simulate N instructions of DDD and an instance of
    itself in the same separate process context that it
    created for DDD.

    The correctly simulated instance of itself creates
    yet another process context to simulate its own
    instance of DDD.
    --
    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 Fri Aug 1 13:22:19 2025
    From Newsgroup: comp.ai.philosophy

    On 8/1/25 12:51 PM, olcott wrote:
    On 8/1/2025 11:00 AM, Richard Damon wrote:
    On 8/1/25 11:44 AM, olcott wrote:
    On 8/1/2025 10:26 AM, joes wrote:
    Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:

    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.

    Yes, after 12 instructions of DDD only or just before the third
    recursive simulation.

    Everyone keeps dishonestly changing my words from
    (a) DDD correctly simulated by HHH (can't possibly halt)

    No, it is that THIS HHH doesn't correctly simulate THIS DDD,


    The outermost directly executed HHH does correctly
    simulate N instructions of DDD and an instance of
    itself in the same separate process context that it
    created for DDD.

    The correctly simulated instance of itself creates
    yet another process context to simulate its own
    instance of DDD.



    And N < M, the number of instructions that the program described will
    run for.

    Since the unaborted process created from the input will halt, it is halting.

    The fact that HHH aborts it before you get there doesn't change that fact.

    Your problem is you don't understand that only N steps correctly
    simulated is not a Correct Simulation, becuase you lie to yourself that
    it can be defined that way.

    Sorry, your lake bottom retreat awaits you.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Fred. Zwarts@F.Zwarts@HetNet.nl to comp.theory,sci.logic,comp.ai.philosophy on Sat Aug 2 11:30:40 2025
    From Newsgroup: comp.ai.philosophy

    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.


    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.



    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.
    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.
    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
  • 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