• Re: Proof that DDD is correctly emulated by an emulated HHH

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

    On 8/2/2025 8:07 AM, Richard Damon wrote:
    On 8/1/25 9:49 PM, olcott wrote:
    On 8/1/2025 7:29 PM, Richard Damon wrote:
    On 8/1/25 8:07 PM, olcott wrote:
    On 8/1/2025 6:57 PM, Richard Damon wrote:
    On 8/1/25 7:38 PM, olcott wrote:
    On 8/1/2025 6:15 PM, Richard Damon wrote:
    On 8/1/25 6:54 PM, olcott wrote:>>
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
    behavior that *THE ACTUAL INPUT* to embedded_H
    specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
    *AN ACTUAL INPUT* to embedded_H so its differing
    behavior *DOES NOT COUNT*.


    NO!!!!

    By that standard, any input could mean anything becuase the
    machine it is being given can do whatever it wants with it.


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    (a) Ĥ copies its input ⟨Ĥ⟩
    (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

    Yes if you ignore that I said that Ĥ.embedded_H
    is based on a UTM and ignore the above is the
    definition of machine Ĥ that could be true.

    "Based on" does not mean *IS*

    If you add code to the original UTM, then it no longer is a UTM,
    and its partial simulation is not determative.


    *That is your one huge mistake*
    As soon as the repeating pattern emerges then
    this repeating pattern *is* determinative.



    But there is no finite pattern that shows non-halting in the
    simulation of DDD.


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

    HHH simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)

    This is stipulated by the basic structure
    of the relationship between DDD and each HHH.




    Then HHH can never abort its simulation to return 0


    As soon as HHH recognizes the repeating pattern it can
    kill the entire simulated process and reject DDD. There
    is no stack unrolling because the process that would do
    that has been killed.
    --
    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 Sat Aug 2 10:16:45 2025
    From Newsgroup: comp.ai.philosophy

    On 8/2/2025 8:07 AM, Richard Damon wrote:
    On 8/1/25 9:52 PM, olcott wrote:
    On 8/1/2025 7:32 PM, Richard Damon wrote:
    On 8/1/25 8:25 PM, olcott wrote:

    My sole purpose is to show that the conventional HP proofs
    do not prove undecidability. I have done that.


    And you ignore that it has been shown that any finite pattern you try
    to detect becomes wrong,
    No this is counter-factual.
    A pattern cannot possibly become wrong.

    It was always wrong.

    Just because a pattern is found in a non-halting program doesn't mean
    that the pattern proves non-halting behavior.


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

    HHH simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)

    This is stipulated by the basic structure
    of the relationship between DDD and each HHH.

    Only if HHH is stipulated to always do a correct simulation, which means
    it can not abort.


    A correct simulation of 2 statements of DDD proves
    a repeating pattern that cannot possibly reach any
    simulated final halt state.

    I showed a correct simulation of 10 statements of DDD
    so that you would look foolish denying that any repeating
    pattern exists.

    int Simulate(ptr x)
    {
    x();
    return 1;
    }

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

    A correct simulation of 2 statements of Infinite_Recursion
    proves a repeating pattern that cannot possibly reach any
    simulated 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 olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy on Sat Aug 2 10:24:02 2025
    From Newsgroup: comp.ai.philosophy

    On 8/2/2025 8:08 AM, Richard Damon wrote:
    On 8/1/25 9:43 PM, olcott wrote:
    On 8/1/2025 7:29 PM, Mr Flibble wrote:
    On Fri, 01 Aug 2025 19:25:54 -0500, olcott wrote:

    On 8/1/2025 7:13 PM, Mr Flibble wrote:
    On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:

    On 8/1/2025 6:57 PM, Richard Damon wrote:
    On 8/1/25 7:38 PM, olcott wrote:
    On 8/1/2025 6:15 PM, Richard Damon wrote:
    On 8/1/25 6:54 PM, olcott wrote:>>
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that
    *THE
    ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>>>>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differing >>>>>>>>>> behavior *DOES NOT COUNT*.


    NO!!!!

    By that standard, any input could mean anything becuase the >>>>>>>>> machine
    it is being given can do whatever it wants with it.


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
    input ⟨Ĥ⟩
    (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

    Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM >>>>>>>> and ignore the above is the definition of machine Ĥ that could be >>>>>>>> true.

    "Based on" does not mean *IS*

    If you add code to the original UTM, then it no longer is a UTM, and >>>>>>> its partial simulation is not determative.


    *That is your one huge mistake*
    As soon as the repeating pattern emerges then this repeating pattern >>>>>> *is* determinative.

    Recognising such a repeating pattern is no different to recognising
    repeated state in a finite state machine however such a recogniser, a >>>>> simulating halt decider, is only a partial decider so of little
    interest as far as the Halting Problem is concerned.

    /Flibble

    My sole purpose is to show that the conventional HP proofs do not prove >>>> undecidability. I have done that.

    No you haven't as what you are trying to show has nothing to do with the >>> Halting Problem which is only concerned with total deciders not partial
    deciders.

    /Flibble

    I have showed that the conventional proofs of the halting problem
    do not prove undecidability. It is reported that there are other
    unconventional proofs. Ben mentioned one of them.

    No, you have not, you have claimed that, but you lie by using the wrong meaning of words.


    int Sipser_D()
    {
       if (HHH(Sipser_D) == 1)
         return 0;
       return 1;
    }

    The proof that recursively enumerable languages are not
    recursive seems to fall into the same trap that I derived.


    And what is your problem here? Nothing in the problem talks about
    recursion,


    int Sipser_D()
    {
    if (HHH(Sipser_D) == 1)
    return 0;
    return 1;
    }

    _Sipser_D()
    [00002162] 55 push ebp
    [00002163] 8bec mov ebp,esp
    [00002165] 6862210000 push 00002162 // push Sipser_D
    [0000216a] e863f4ffff call 000015d2 // call HHH
    [0000216f] 83c404 add esp,+04
    [00002172] 83f801 cmp eax,+01
    [00002175] 7504 jnz 0000217b
    [00002177] 33c0 xor eax,eax
    [00002179] eb05 jmp 00002180
    [0000217b] b801000000 mov eax,00000001
    [00002180] 5d pop ebp
    [00002181] c3 ret
    Size in bytes:(0032) [00002181]

    Sipser_D correctly emulated by HHH remains stuck in
    recursive emulation until HHH aborts its emulation
    and then kills the whole Sipser_D process before it
    ever reaches the "if" statement. The HHH is correct
    to return 0 rejecting Sipser_D() as non halting.
    --
    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:47:10 2025
    From Newsgroup: comp.ai.philosophy

    On 8/2/25 11:10 AM, olcott wrote:
    On 8/2/2025 8:07 AM, Richard Damon wrote:
    On 8/1/25 9:49 PM, olcott wrote:
    On 8/1/2025 7:29 PM, Richard Damon wrote:
    On 8/1/25 8:07 PM, olcott wrote:
    On 8/1/2025 6:57 PM, Richard Damon wrote:
    On 8/1/25 7:38 PM, olcott wrote:
    On 8/1/2025 6:15 PM, Richard Damon wrote:
    On 8/1/25 6:54 PM, olcott wrote:>>
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
    behavior that *THE ACTUAL INPUT* to embedded_H
    specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
    *AN ACTUAL INPUT* to embedded_H so its differing
    behavior *DOES NOT COUNT*.


    NO!!!!

    By that standard, any input could mean anything becuase the
    machine it is being given can do whatever it wants with it.


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    (a) Ĥ copies its input ⟨Ĥ⟩
    (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

    Yes if you ignore that I said that Ĥ.embedded_H
    is based on a UTM and ignore the above is the
    definition of machine Ĥ that could be true.

    "Based on" does not mean *IS*

    If you add code to the original UTM, then it no longer is a UTM,
    and its partial simulation is not determative.


    *That is your one huge mistake*
    As soon as the repeating pattern emerges then
    this repeating pattern *is* determinative.



    But there is no finite pattern that shows non-halting in the
    simulation of DDD.


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

    HHH simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)

    This is stipulated by the basic structure
    of the relationship between DDD and each HHH.




    Then HHH can never abort its simulation to return 0


    As soon as HHH recognizes the repeating pattern it can
    kill the entire simulated process and reject DDD. There
    is no stack unrolling because the process that would do
    that has been killed.


    No it can't as the pattern is NOT non-halting if the HHH that was being simulated will also abort its simulation and return 0, and it will if
    the outer HHH does.

    Remember, Halting/Non-Halting is a property of the undisturbed program,
    and thus continues after HHH decides to abort its simulation.

    All you are doing is proving you don't understand what you are talking
    about, because you logic system is based on lies.
    --- 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:47:14 2025
    From Newsgroup: comp.ai.philosophy

    On 8/2/25 11:16 AM, olcott wrote:
    On 8/2/2025 8:07 AM, Richard Damon wrote:
    On 8/1/25 9:52 PM, olcott wrote:
    On 8/1/2025 7:32 PM, Richard Damon wrote:
    On 8/1/25 8:25 PM, olcott wrote:

    My sole purpose is to show that the conventional HP proofs
    do not prove undecidability. I have done that.


    And you ignore that it has been shown that any finite pattern you
    try to detect becomes wrong,
    No this is counter-factual.
    A pattern cannot possibly become wrong.

    It was always wrong.

    Just because a pattern is found in a non-halting program doesn't mean
    that the pattern proves non-halting behavior.


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

    HHH simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)

    This is stipulated by the basic structure
    of the relationship between DDD and each HHH.

    Only if HHH is stipulated to always do a correct simulation, which
    means it can not abort.


    A correct simulation of 2 statements of DDD proves
    a repeating pattern that cannot possibly reach any
    simulated final halt state.

    Nope. Try to PROVE it.

    Rememver, DDD must be a PROGRAM will ALL its code or you have a category error.

    The correct simulation of a call instruction goes into the function
    called, and shows the operation of that program.

    A correct simulation doesn't stop until you reach a final state, as all instruciton include as part of their definition (except final
    instructions) and execute the next instruction in program flow order.


    I showed a correct simulation of 10 statements of DDD
    so that you would look foolish denying that any repeating
    pattern exists.

    Nope, as "that simulates DDD" isn't an x86 simulation of the input.

    It isn't even a correct definition of what HHH does unless you HHH is
    defined to NEVER abort (and thus your outer HHH can't either, and thus
    fails to be a decider).


    int Simulate(ptr x)
    {
      x();
      return 1;
    }

    Pretty bad concept of simulator.


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

    A correct simulation of 2 statements of Infinite_Recursion
    proves a repeating pattern that cannot possibly reach any
    simulated final halt state.


    So?

    DDD doesn't call Simulate, it calls HHH, which only CONDITIONALLY
    simulates and WILL abort at some point if HHH(DDD) returns an answer
    anywhere.

    All you are doing is proving that you lie about what thing are.
    --- 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:47:19 2025
    From Newsgroup: comp.ai.philosophy

    On 8/2/25 11:24 AM, olcott wrote:
    On 8/2/2025 8:08 AM, Richard Damon wrote:
    On 8/1/25 9:43 PM, olcott wrote:
    On 8/1/2025 7:29 PM, Mr Flibble wrote:
    On Fri, 01 Aug 2025 19:25:54 -0500, olcott wrote:

    On 8/1/2025 7:13 PM, Mr Flibble wrote:
    On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:

    On 8/1/2025 6:57 PM, Richard Damon wrote:
    On 8/1/25 7:38 PM, olcott wrote:
    On 8/1/2025 6:15 PM, Richard Damon wrote:
    On 8/1/25 6:54 PM, olcott wrote:>>
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that
    *THE
    ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot
    possibly be *AN ACTUAL INPUT* to embedded_H so its differing >>>>>>>>>>> behavior *DOES NOT COUNT*.


    NO!!!!

    By that standard, any input could mean anything becuase the >>>>>>>>>> machine
    it is being given can do whatever it wants with it.


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
    input ⟨Ĥ⟩
    (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

    Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM >>>>>>>>> and ignore the above is the definition of machine Ĥ that could be >>>>>>>>> true.

    "Based on" does not mean *IS*

    If you add code to the original UTM, then it no longer is a UTM, >>>>>>>> and
    its partial simulation is not determative.


    *That is your one huge mistake*
    As soon as the repeating pattern emerges then this repeating pattern >>>>>>> *is* determinative.

    Recognising such a repeating pattern is no different to recognising >>>>>> repeated state in a finite state machine however such a recogniser, a >>>>>> simulating halt decider, is only a partial decider so of little
    interest as far as the Halting Problem is concerned.

    /Flibble

    My sole purpose is to show that the conventional HP proofs do not
    prove
    undecidability. I have done that.

    No you haven't as what you are trying to show has nothing to do with
    the
    Halting Problem which is only concerned with total deciders not partial >>>> deciders.

    /Flibble

    I have showed that the conventional proofs of the halting problem
    do not prove undecidability. It is reported that there are other
    unconventional proofs. Ben mentioned one of them.

    No, you have not, you have claimed that, but you lie by using the
    wrong meaning of words.


    int Sipser_D()
    {
       if (HHH(Sipser_D) == 1)
         return 0;
       return 1;
    }

    The proof that recursively enumerable languages are not
    recursive seems to fall into the same trap that I derived.


    And what is your problem here? Nothing in the problem talks about
    recursion,


    int Sipser_D()
    {
      if (HHH(Sipser_D) == 1)
        return 0;
      return 1;
    }

    _Sipser_D()
    [00002162] 55             push ebp
    [00002163] 8bec           mov ebp,esp
    [00002165] 6862210000     push 00002162 // push Sipser_D
    [0000216a] e863f4ffff     call 000015d2 // call HHH
    [0000216f] 83c404         add esp,+04
    [00002172] 83f801         cmp eax,+01
    [00002175] 7504           jnz 0000217b
    [00002177] 33c0           xor eax,eax
    [00002179] eb05           jmp 00002180
    [0000217b] b801000000     mov eax,00000001
    [00002180] 5d             pop ebp
    [00002181] c3             ret
    Size in bytes:(0032) [00002181]

    Sipser_D correctly emulated by HHH remains stuck in
    recursive emulation until HHH aborts its emulation
    and then kills the whole Sipser_D process before it
    ever reaches the "if" statement. The HHH is correct
    to return 0 rejecting Sipser_D() as non halting.


    And thus HHH didn't correctly simulate Sipser_D. Partial simulation,
    even correct simulation until ,,, are not "correct simulations", just
    like starting to run a marathon, but stopping after 100 feet is not
    running a marathon.

    And Sipser_D when RUN, which is what the problem statement asks about,
    will call HHH(Sipser_D) which will do that exact same thing and return 0
    and Sipser_D will return 1 to make it wrong.

    The question put to HHH says NOTHING about the deciders simulation of
    the input program, only about the behavior of the input program.

    It doesn't matter that HHH thinks it can't simulate to a final state,
    and the definition of HHH was fixed when the program ran, so it needs to
    treat the input as the exact input.

    Note, in the programing langauge Sipser used, programs WERE valid inputs
    to programs, no representation was needed (it was handled by the
    language itself).
    --- Synchronet 3.21a-Linux NewsLink 1.2