1. Forum
  2. Usenet
  3. COMP.THEORY

  • Re: Simulation vs. Execution in the Halting Problem --- Linz

    From Mr Flibble@21:1/5 to olcott on Sat May 31 17:05:14 2025
    On Sat, 31 May 2025 11:45:21 -0500, olcott wrote:

    On 5/31/2025 7:35 AM, Richard Damon wrote:
    On 5/31/25 2:41 AM, olcott wrote:
    On 5/30/2025 8:16 PM, Richard Damon wrote:
    On 5/30/25 11:41 AM, olcott wrote:
    On 5/30/2025 3:45 AM, Mikko wrote:
    On 2025-05-29 18:10:39 +0000, olcott said:

    On 5/29/2025 12:34 PM, Mr Flibble wrote:

    🧠 Simulation vs. Execution in the Halting Problem

    In the classical framework of computation theory (Turing
    machines),
    simulation is not equivalent to execution, though they can
    approximate one another.

    To the best of my knowledge a simulated input always has the exact >>>>>>> same behavior as the directly executed input unless this simulated >>>>>>> input calls its own simulator.

    The simulation of the behaviour should be equivalent to the real
    behaviour.

    That is the same as saying a function with infinite recursion must
    have the same behavior as a function without infinite recursion.

    Nope. Where does it say that?


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

    DDD emulated by HHH must be aborted.   // otherwise infinite recursion >>> DDD emulated by HHH1 need not be aborted.


    No, nether HHH or HHH1 can correctly emulate this input, as it is
    incomplete, andt eh call HHH is IMPOSSIBLE to emulate in this input, as
    its target is not in the input, so any action that looks elsewhere for
    it is just not emulating THIS INPUT.

    Sorry, your acknoldegement that you DDD just isn't a program means that
    its representation is NOT correctly emulatable.

    Fix that issue by including in the input the code of the HHH that
    calling it, and we find that HHH just doesn't correctly emulate it, as
    it has been defined, in halt7.c, to chose to abort at a spot where the
    program does not stop.

    Of course, in your mind HHH isn't a program either, as you refuse to
    accept that it must be a single program. Note, an infinite set of
    programs is not A program.


    Thus, you have admitted that your whole system of logic is based on
    using incorrect definitions and lies.

    Your problem is you don't understand that the only things you can
    correctly simulate are PROGRAMS, which mean they include all of their
    code, which is also expressed in the input given to the simulator.


    Whether it actually is depends on the quality of the simulator.
    There is no exception for the case when the simulator is called. If >>>>>> the behaviour in the simulation is different from a real execution >>>>>> then the simulation is wrong.


    A function that calls its own simulator specifies different behavior >>>>> than a function that does not call its own simulator.

    No it doesn't, as we can only be talking about programs, and programs
    don't know who "their simulator" is, only what simulator they were
    built to use.


    One of the advantages of Turing machines is that there is no
    possibility to call anything so the effect of calling the simulator >>>>>> need not be considered.


    The same issue occurs in the Linz proof, it is merely more difficult >>>>> to see. The correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its
    own simulated final halt state ⟨Ĥ.qn⟩

    What "Issue"? Your problme is you don't understand what you are
    taling about.


    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ Ĥ.q0 ⟨Ĥ⟩ ⊢*
    embedded_H ⟨Ĥ⟩
    ⟨Ĥ⟩ ⊢* Ĥ.qn

    Why did the copy of H change to being called "embedded_H"?


    I am using cleaner notational conventions.

    How is using two names for the same thing cleaner?



    (a) Ĥ copies its input ⟨Ĥ⟩
    (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
    (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
    (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
    (g) goto (d) with one more level of simulation


    Which then gets stop when the embedded_H invoked at the first
    invocation of (b) doing step (c) decides to abort its emulation.


    I have it emulate one more level before stopping.
    It would stop at (e).

    Rigth, so you go (a) (b) (c) (e) (h) return to H^.qn (i) H^ Halts

    Thus showing the input is non-halting.


    *EVERYONE ALWAYS GETS THIS WRONG*

    int main()
    {
    DDD(); // The HHH that DDD calls is not supposed to
    } // report on the behavior of its caller, nitwit

    Likewise embedded_H is not supposed to report on the behavior of the computation that itself is embedded within.

    I think I see where you are going wrong: HHH has to call DDD in main();
    HHH has to be the outermost context for a halting result of NON-HALTING to
    be valid.

    /Flibble

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat May 31 14:26:26 2025
    On 5/31/25 12:45 PM, olcott wrote:
    On 5/31/2025 7:35 AM, Richard Damon wrote:
    On 5/31/25 2:41 AM, olcott wrote:
    On 5/30/2025 8:16 PM, Richard Damon wrote:
    On 5/30/25 11:41 AM, olcott wrote:
    On 5/30/2025 3:45 AM, Mikko wrote:
    On 2025-05-29 18:10:39 +0000, olcott said:

    On 5/29/2025 12:34 PM, Mr Flibble wrote:

    🧠 Simulation vs. Execution in the Halting Problem

    In the classical framework of computation theory (Turing machines), >>>>>>>> simulation is not equivalent to execution, though they can
    approximate one
    another.

    To the best of my knowledge a simulated input
    always has the exact same behavior as the directly
    executed input unless this simulated input calls
    its own simulator.

    The simulation of the behaviour should be equivalent to the real
    behaviour.

    That is the same as saying a function with infinite
    recursion must have the same behavior as a function
    without infinite recursion.

    Nope. Where does it say that?


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

    DDD emulated by HHH must be aborted.   // otherwise infinite recursion >>> DDD emulated by HHH1 need not be aborted.


    No, nether HHH or HHH1 can correctly emulate this input, as it is
    incomplete, andt eh call HHH is IMPOSSIBLE to emulate in this input,
    as its target is not in the input, so any action that looks elsewhere
    for it is just not emulating THIS INPUT.

    Sorry, your acknoldegement that you DDD just isn't a program means
    that its representation is NOT correctly emulatable.

    Fix that issue by including in the input the code of the HHH that
    calling it, and we find that HHH just doesn't correctly emulate it, as
    it has been defined, in halt7.c, to chose to abort at a spot where the
    program does not stop.

    Of course, in your mind HHH isn't a program either, as you refuse to
    accept that it must be a single program. Note, an infinite set of
    programs is not A program.


    Thus, you have admitted that your whole system of logic is based on
    using incorrect definitions and lies.

    Your problem is you don't understand that the only things you can
    correctly simulate are PROGRAMS, which mean they include all of
    their code, which is also expressed in the input given to the
    simulator.


    Whether it actually is depends on the quality of the
    simulator. There is no exception for the case when the simulator
    is called. If the behaviour in the simulation is different from
    a real execution then the simulation is wrong.


    A function that calls its own simulator specifies different
    behavior than a function that does not call its own simulator.

    No it doesn't, as we can only be talking about programs, and
    programs don't know who "their simulator" is, only what simulator
    they were built to use.


    One of the advantages of Turing machines is that there is no
    possibility
    to call anything so the effect of calling the simulator need not be >>>>>> considered.


    The same issue occurs in the Linz proof, it is merely more
    difficult to see. The correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩ cannot
    possibly reach its own simulated final halt state ⟨Ĥ.qn⟩

    What "Issue"? Your problme is you don't understand what you are
    taling about.


    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    Why did the copy of H change to being called "embedded_H"?


    I am using cleaner notational conventions.

    How is using two names for the same thing cleaner?



    (a) Ĥ copies its input ⟨Ĥ⟩
    (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
    (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
    (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
    (g) goto (d) with one more level of simulation


    Which then gets stop when the embedded_H invoked at the first
    invocation of (b) doing step (c) decides to abort its emulation.


    I have it emulate one more level before stopping.
    It would stop at (e).

    Rigth, so you go (a) (b) (c) (e) (h) return to H^.qn (i) H^ Halts

    Thus showing the input is non-halting.


    *EVERYONE ALWAYS GETS THIS WRONG*

    How, since it is. Or are you just showing you think lying is ok


    int main()
    {
      DDD(); // The HHH that DDD calls is not supposed to
    }        // report on the behavior of its caller, nitwit

    Likewise embedded_H is not supposed to report on the
    behavior of the computation that itself is embedded within.


    Right, it reports on the behavior of the computation that is represented
    to it, even if that just happens to be its caller.

    You are just showing that you don't understand the basic meaning of the
    terms you are using, and that you recklessly refuse to learn them.

    It seems your idea of "logic" isn't based on actual logic, but on your
    ability to lie.

    Sorry, but that *IS* what you are telling the world by your actions.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat May 31 14:30:51 2025
    On 5/31/25 1:20 PM, olcott wrote:
    On 5/31/2025 12:05 PM, Mr Flibble wrote:
    On Sat, 31 May 2025 11:45:21 -0500, olcott wrote:

    On 5/31/2025 7:35 AM, Richard Damon wrote:
    On 5/31/25 2:41 AM, olcott wrote:
    On 5/30/2025 8:16 PM, Richard Damon wrote:
    On 5/30/25 11:41 AM, olcott wrote:
    On 5/30/2025 3:45 AM, Mikko wrote:
    On 2025-05-29 18:10:39 +0000, olcott said:

    On 5/29/2025 12:34 PM, Mr Flibble wrote:

    🧠 Simulation vs. Execution in the Halting Problem

    In the classical framework of computation theory (Turing
    machines),
    simulation is not equivalent to execution, though they can >>>>>>>>>> approximate one another.

    To the best of my knowledge a simulated input always has the exact >>>>>>>>> same behavior as the directly executed input unless this simulated >>>>>>>>> input calls its own simulator.

    The simulation of the behaviour should be equivalent to the real >>>>>>>> behaviour.

    That is the same as saying a function with infinite recursion must >>>>>>> have the same behavior as a function without infinite recursion.

    Nope. Where does it say that?


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

    DDD emulated by HHH must be aborted.   // otherwise infinite recursion >>>>> DDD emulated by HHH1 need not be aborted.


    No, nether HHH or HHH1 can correctly emulate this input, as it is
    incomplete, andt eh call HHH is IMPOSSIBLE to emulate in this input, as >>>> its target is not in the input, so any action that looks elsewhere for >>>> it is just not emulating THIS INPUT.

    Sorry, your acknoldegement that you DDD just isn't a program means that >>>> its representation is NOT correctly emulatable.

    Fix that issue by including in the input the code of the HHH that
    calling it, and we find that HHH just doesn't correctly emulate it, as >>>> it has been defined, in halt7.c, to chose to abort at a spot where the >>>> program does not stop.

    Of course, in your mind HHH isn't a program either, as you refuse to
    accept that it must be a single program. Note, an infinite set of
    programs is not A program.


    Thus, you have admitted that your whole system of logic is based on
    using incorrect definitions and lies.

    Your problem is you don't understand that the only things you can
    correctly simulate are PROGRAMS, which mean they include all of their >>>>>> code, which is also expressed in the input given to the simulator. >>>>>>

    Whether it actually is depends on the quality of the simulator. >>>>>>>> There is no exception for the case when the simulator is called. If >>>>>>>> the behaviour in the simulation is different from a real execution >>>>>>>> then the simulation is wrong.


    A function that calls its own simulator specifies different behavior >>>>>>> than a function that does not call its own simulator.

    No it doesn't, as we can only be talking about programs, and programs >>>>>> don't know who "their simulator" is, only what simulator they were >>>>>> built to use.


    One of the advantages of Turing machines is that there is no
    possibility to call anything so the effect of calling the simulator >>>>>>>> need not be considered.


    The same issue occurs in the Linz proof, it is merely more difficult >>>>>>> to see. The correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach >> its
    own simulated final halt state ⟨Ĥ.qn⟩

    What "Issue"? Your problme is you don't understand what you are
    taling about.


    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ Ĥ.q0 ⟨Ĥ⟩ ⊢*
    embedded_H ⟨Ĥ⟩
    ⟨Ĥ⟩ ⊢* Ĥ.qn

    Why did the copy of H change to being called "embedded_H"?


    I am using cleaner notational conventions.

    How is using two names for the same thing cleaner?



    (a) Ĥ copies its input ⟨Ĥ⟩
    (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
    (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
    (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
    (g) goto (d) with one more level of simulation


    Which then gets stop when the embedded_H invoked at the first
    invocation of (b) doing step (c) decides to abort its emulation.


    I have it emulate one more level before stopping.
    It would stop at (e).

    Rigth, so you go (a) (b) (c) (e) (h) return to H^.qn (i) H^ Halts

    Thus showing the input is non-halting.


    *EVERYONE ALWAYS GETS THIS WRONG*

    int main()
    {
        DDD(); // The HHH that DDD calls is not supposed to
    }        // report on the behavior of its caller, nitwit

    Likewise embedded_H is not supposed to report on the behavior of the
    computation that itself is embedded within.

    I think I see where you are going wrong: HHH has to call DDD in main();
    HHH has to be the outermost context for a halting result of NON-
    HALTING to
    be valid.

    /Flibble

    /Flibble


    It is always correct for every HHH(DDD) to reject its
    input as specifying a non-halting sequence of
    configurations.

    No, it is NEVER correct for any HHH(DDD) that returns the answer 0 to
    return that answer, as then the DDD, that includes the code for THAT
    HHH, that returns the value 0, will be a HALTING computation.


    The fact that the directly executed DDD() that calls
    HHH(DDD) does halt is none-of-the-business of HHH.

    Right, but the fact that DDD that it was given will halt when it is
    directly executed is the basis of determining the correct answer.

    HHH(DDD) needs to return the correct answer to ANYONE who asks it, and
    that includes the DDD that is being directly executed.


    HHH is only accountable for the behavior that its
    actual input actually specifies.


    Which is the behavior of the direct execution of the program its input represents.


    *This seems to be brand new computer science*


    No, you are just working in BROKEN computer science, since you don't
    even understand the nature of what a program is, even though that is the fundamental block which your decider is supposed to be and is working on.

    Sorry, you are just proving your stupidity.

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