• Re: Halting and the Impossible Program: A Semantic Reinterpretation

    From olcott@polcott333@gmail.com to comp.theory,comp.ai.philosophy,sci.logic on Fri Aug 1 09:31:33 2025
    From Newsgroup: comp.ai.philosophy

    On 8/1/2025 7:38 AM, Alan Mackenzie wrote:
    olcott <polcott333@gmail.com> wrote:

    [ .... ]

    Alternatively halt deciders never were accountable
    for the direct execution of their inputs because
    no Turing machine can take a directly executing
    Turing machine as an input.

    It's not clear what you mean by a "directly executing turing machine".
    Turing machines are abstract constructs which only secondarily can be physically instantiated. What does it mean for a TM to be "directly executing", and how does that differ from "indirectly executing"?


    *From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
    Ĥ.embedded_H is the Lina Halt Decider H.

    Definition of the Linz Turing Machine Ĥ
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
    its simulated final halt state of ⟨Ĥ.qn⟩, and

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
    reach its simulated final halt state of ⟨Ĥ.qn⟩.

    It might be best to read the whole four page Peter Linz
    proof to get the full background.

    My augmentation to the Turing machine proof is to
    assumed that Ĥ.embedded_H is based on a UTM. Thus a
    simulating halt decider.

    Ĥ applied to ⟨Ĥ⟩ is direct execution.
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not direct execution.

    Halt deciders are only accountable for the behavior
    that their input finite string Turing machine
    description specifies.

    If the initial state of the TM's tape can be construed as a string, then
    yes.


    It is a sequence of tape cells containing values, thus
    essentially a string. For halt deciders this finite string
    must be a machine description.

    This is only different than the direct execution
    of the underlying machine when the input calls
    its own decider (in recursive simulation).

    Again, you haven't defined "direct execution".


    I have defined it above.

    It is unclear what you mean by "its own decider". What, for example, is
    the decider of a program which adds two integers? I think you're getting confused between a purported decider "having" a program which breaks it (which they all do), and an arbitrary program "having" a decider (which
    is non-sensical).


    When Ĥ applied to ⟨Ĥ⟩ then Ĥ.embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
    we have one machine that contains a decider and this same
    machine is applied to its own machine description.

    The interesting part comes next.

    --
    Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer

    --
    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,comp.ai.philosophy,sci.logic on Fri Aug 1 10:55:03 2025
    From Newsgroup: comp.ai.philosophy

    On 8/1/25 10:31 AM, olcott wrote:
    On 8/1/2025 7:38 AM, Alan Mackenzie wrote:
    olcott <polcott333@gmail.com> wrote:

    [ .... ]

    Alternatively halt deciders never were accountable
    for the direct execution of their inputs because
    no Turing machine can take a directly executing
    Turing machine as an input.

    It's not clear what you mean by a "directly executing turing machine".
    Turing machines are abstract constructs which only secondarily can be
    physically instantiated.  What does it mean for a TM to be "directly
    executing", and how does that differ from "indirectly executing"?


    *From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
    Ĥ.embedded_H is the Lina Halt Decider H.

    Definition of the Linz Turing Machine Ĥ
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
       if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
       its simulated final halt state of ⟨Ĥ.qn⟩, and

    No, if Ĥ applied to ⟨Ĥ⟩ reaches a final state


    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
       if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
       reach its simulated final halt state of ⟨Ĥ.qn⟩.


    No, if Ĥ applied to ⟨Ĥ⟩ will never reach a final state after an unbounded number of steps


    It might be best to read the whole four page Peter Linz
    proof to get the full background.

    Maybe you should, and stop lying about what it says.


    My augmentation to the Turing machine proof is to
    assumed that Ĥ.embedded_H is based on a UTM. Thus a
    simulating halt decider.

    Ĥ applied to ⟨Ĥ⟩ is direct execution.
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not direct execution.

    But the criteria is if Ĥ applied to ⟨Ĥ⟩ reaches a final state, i.e the direct exection,

    It was NEVER about the simulation done by Ĥ.embedded_H so you can't
    change it to that.

    All you are doing is showing that you don't know what you are talking
    about and don't mind lying about it.



    Halt deciders are only accountable for the behavior
    that their input finite string Turing machine
    description specifies.

    If the initial state of the TM's tape can be construed as a string, then
    yes.


    It is a sequence of tape cells containing values, thus
    essentially a string. For halt deciders this finite string
    must be a machine description.

    Right, the the correct answer for the halt decider is based on the
    direct execution of the machine it is a description of.


    This is only different than the direct execution
    of the underlying machine when the input calls
    its own decider (in recursive simulation).

    Again, you haven't defined "direct execution".


    I have defined it above.

    It is unclear what you mean by "its own decider".  What, for example, is
    the decider of a program which adds two integers?  I think you're getting >> confused between a purported decider "having" a program which breaks it
    (which they all do), and an arbitrary program "having" a decider (which
    is non-sensical).


    When Ĥ applied to ⟨Ĥ⟩ then Ĥ.embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ we have one machine that contains a decider and this same
    machine is applied to its own machine description.

    The interesting part comes next.

    But, since we don't care about what the PARTIAL (and thus not correct) simulation shows, the rest is just lies.

    All you are doing is admitting that you haven't properly defined or used
    your machine description language, or the "behavior" of that string
    would match the behavior of the directly executed machine.


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