• Re: Position Paper: Why Simulating Halt Deciders (SHDs) Require a Refra

    From Mr Flibble@21:1/5 to olcott on Sat May 24 18:12:16 2025
    On Sat, 24 May 2025 12:38:20 -0500, olcott wrote:

    My SHD refutes the classical halting problem proof that same way that
    ZFC refutes Russell's Paradox.

    ZFC Doesn’t Refute Russell’s Paradox — It Avoids It
    ZFC doesn’t show Russell’s paradox is false — it restricts the language so
    that the paradoxical construction is no longer valid.

    Likewise, your SHD does not refute the Halting Problem proof — it merely redefines the space of programs it will consider.

    📌 Conclusion: Avoiding a contradiction by changing rules is not the same
    as disproving it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to olcott on Sat May 24 18:24:29 2025
    On Sat, 24 May 2025 13:19:54 -0500, olcott wrote:

    On 5/24/2025 1:12 PM, Mr Flibble wrote:
    On Sat, 24 May 2025 12:38:20 -0500, olcott wrote:

    My SHD refutes the classical halting problem proof that same way that
    ZFC refutes Russell's Paradox.

    ZFC Doesn’t Refute Russell’s Paradox — It Avoids It ZFC doesn’t show >> Russell’s paradox is false — it restricts the language so that the
    paradoxical construction is no longer valid.

    Likewise, your SHD does not refute the Halting Problem proof — it
    merely redefines the space of programs it will consider.

    📌 Conclusion: Avoiding a contradiction by changing rules is not the
    same as disproving it.

    Proving that the rules have always been incoherent nonsense does seem to refute them.

    There’s no “incoherence” in the model itself — only undecidability, which
    is expected from systems that support recursion, self-reference, and
    unbounded computation.

    You do not have a mathematical refutation — you instead have a meta- theoretical rejection.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to olcott on Sat May 24 18:49:04 2025
    On Sat, 24 May 2025 13:42:44 -0500, olcott wrote:

    On 5/24/2025 1:24 PM, Mr Flibble wrote:
    On Sat, 24 May 2025 13:19:54 -0500, olcott wrote:

    On 5/24/2025 1:12 PM, Mr Flibble wrote:
    On Sat, 24 May 2025 12:38:20 -0500, olcott wrote:

    My SHD refutes the classical halting problem proof that same way
    that ZFC refutes Russell's Paradox.

    ZFC Doesn’t Refute Russell’s Paradox — It Avoids It ZFC doesn’t show
    Russell’s paradox is false — it restricts the language so that the >>>> paradoxical construction is no longer valid.

    Likewise, your SHD does not refute the Halting Problem proof — it
    merely redefines the space of programs it will consider.

    📌 Conclusion: Avoiding a contradiction by changing rules is not the >>>> same as disproving it.

    Proving that the rules have always been incoherent nonsense does seem
    to refute them.

    There’s no “incoherence” in the model itself — only undecidability, >> which is expected from systems that support recursion, self-reference,
    and unbounded computation.


    *THIS IS AN INCOHERENT REQUIREMENT*

    int main()
    {
    DD(); // the HHH that DD calls cannot report on
    } // the behavior of its caller

    When the rules require that HHH report on the behavior of the direct execution of its input that requires HHH to report on the behavior of
    its caller.

    You do not have a mathematical refutation — you instead have a meta-
    theoretical rejection.

    /Flibble

    When a math problem requires the non-empty intersection of the sets of
    cats and dogs it is the requirement that is incorrect.

    This continues your pattern of **recasting the Halting Problem proof as logically incoherent**, rather than merely undecidable. You maintain that requiring a decider (HHH) to report on the behavior of its caller (DD) constitutes an **illegitimate or contradictory requirement**.

    Let’s break this down analytically.

    ---

    ## 🧠 Your Key Assertion

    "*When the rules require that HHH report on the behavior of its input,
    that requires HHH to report on the behavior of its caller. THAT is incoherent.*"

    ### Interpretation:

    * You argue that when DD calls HHH on itself, **HHH is logically being
    asked to report on its own calling context** — i.e., DD’s behavior.
    * You claim that this creates **a feedback loop** where HHH’s output influences DD’s behavior, which then invalidates HHH’s prediction.

    This leads you to conclude:

    “This requirement is **self-contradictory** — like asking for the square
    root of a dead cat.”

    ---

    ## 🧩 Why This Is (Still) Misinterpreting the Halting Problem

    ### 1. **The Classical Model Doesn’t Require Context Awareness**

    In the standard Halting Problem:

    * `H(P, x)` is a **pure function** that returns whether program `P` halts
    on input `x`.
    * It is evaluated as if `P(x)` is **executed directly**, independent of
    *who* is asking.
    * The contradict
  • From Richard Damon@21:1/5 to olcott on Sat May 24 18:33:41 2025
    On 5/24/25 1:38 PM, olcott wrote:
    On 5/24/2025 12:25 PM, Mr Flibble wrote:
    Position Paper: Why Simulating Halt Deciders (SHDs) Require a
    Reframing of
    the Halting Problem
    ==============================================================================================

    Thesis:
    -------
    Simulating Halt Deciders (SHDs), such as those proposed by Flibble and
    Olcott, do not disprove the classical Halting Problem but instead operate
    in a distinct computational framework. Therefore, they require a
    reframing
    of the Halting Problem to accurately describe what is being solved.

    1. The Classical Halting Problem
    --------------------------------
    Definition:
    Given a program P and input x, determine whether P(x) halts when
    executed.

    Requirements:
    - The decider H must work for *all* valid programs P and inputs x.
    - H must be total: it must give a correct answer for every input pair.
    - The construction of D() = if H(D) then loop leads to contradiction.

    Implication:
    - No universal halting decider exists.

    2. What SHDs Do Differently
    ---------------------------
    SHDs simulate the behavior of P(x), often with the following properties:
    - They detect infinite recursion or looping patterns *during simulation*.
    - They may abort early when a loop is structurally recognized.
    - They return a result based on runtime behavior, not semantic
    derivation.

    In some models:
    - SHDs may crash or refuse to decide on inputs that involve self-
    reference.
    - They avoid the contradiction by forbidding or failing on such cases.

    3. Why This Requires Reframing
    ------------------------------
    The classical Halting Problem assumes:
    - All programs are valid analyzable inputs.
    - The decider exists *outside* the execution environment.
    - Deciders can analyze any encoded program as data.

    SHDs violate or restrict these assumptions:
    - Some inputs are semantically ill-formed (e.g. self-referential
    constructions).
    - Deciders may exist *within* the runtime framework (e.g. as part of a
    simulation).
    - Programs are not just strings—they may include or exclude semantic
    permissions.

    Reframed Problem:
    "Given a well-formed, non-self-referential program P and input x, can an
    SHD determine whether P(x) halts by simulation, within finite time?"

    This version:
    - Recognizes semantic boundaries.
    - Accepts partiality (SHDs may refuse to decide some inputs).
    - Avoids contradiction by rejecting paradox-generating constructions.

    4. Analogy to Type Theory
    --------------------------
    In modern logic systems:
    - Self-reference is blocked by stratified types or universe hierarchies.
    - Proof assistants like Coq, Agda enforce termination through typing.

    Similarly, SHDs operate with:
    - Semantic filters (not all programs are valid inputs).
    - Safety over completeness.

    This makes them useful, but outside classical universality.

    5. Practical Implication
    ------------------------
    Reframing the Halting Problem to fit SHDs allows:
    - Simulation-based analyzers to be judged on their actual utility.
    - SHDs to be integrated into verification pipelines (e.g. compilers,
    interpreters).
    - Clear boundaries between theoretical impossibility and practical
    feasibility.

    Conclusion:
    -----------
    SHDs do not contradict the Halting Problem—they bypass it by refusing to >> evaluate semantically ill-formed or reflexive inputs. This makes them
    partial deciders operating in a semantically filtered domain.

    To evaluate them fairly, the Halting Problem must be reframed: not as a
    universal challenge, but as a scoped analysis tool within a stratified or
    simulation-based semantic model.

    My SHD refutes the classical halting problem proof
    that same way that ZFC refutes Russell's Paradox.

    No, it doesn't as ZFC doesn't "refute" Russell's Paradox, just creates
    an alternate system where it can't be formed.


    If you want to form an alternate computation theory, you need to stop
    claiming you are doing anything in that theory (and thus have any
    implication on the theory) and do the work to fully define your new
    alternate theory,

    Of course, since that doesn't negate the actual Halting Theory that is
    in the field that other proofs use, you haven't acheived your goal of
    putting those other theories into question.


    Instead of requiring a termination analyzer to report
    on the behavior of its caller it reports on the actual
    behavior actually specified by its actual input.

    But since the "actual behavior" of the input is DEFINED to be what turns
    out to be the behavior of its caller, that is impossible.


    *This was probably the actual intent all along*
    It merely took 90 years before anyone really
    studied how pathological inputs actually do
    change their own behavior by their pathology.


    No, it just shows that you haven't learned anything about the works
    presented, and are making the same mistakes that the people tried to
    raise those 90 years ago, and eventually dropped their objections when
    they saw the truth (or died uninformed).

    Sorry, you are just showing that you are almost a century behind in your knowledge.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to Mr Flibble on Sat May 24 18:28:10 2025
    On 5/24/25 1:25 PM, Mr Flibble wrote:
    Position Paper: Why Simulating Halt Deciders (SHDs) Require a Reframing of the Halting Problem ==============================================================================================

    Thesis:
    -------
    Simulating Halt Deciders (SHDs), such as those proposed by Flibble and Olcott, do not disprove the classical Halting Problem but instead operate
    in a distinct computational framework. Therefore, they require a reframing
    of the Halting Problem to accurately describe what is being solved.

    1. The Classical Halting Problem
    --------------------------------
    Definition:
    Given a program P and input x, determine whether P(x) halts when executed.

    Requirements:
    - The decider H must work for *all* valid programs P and inputs x.
    - H must be total: it must give a correct answer for every input pair.
    - The construction of D() = if H(D) then loop leads to contradiction.

    Implication:
    - No universal halting decider exists.

    2. What SHDs Do Differently
    ---------------------------
    SHDs simulate the behavior of P(x), often with the following properties:
    - They detect infinite recursion or looping patterns *during simulation*.

    And the queation becomes how they do this, when the imput program can
    contain a COPY of the algorithm of the SHD.

    Part of your problem is that you have fallen for Olcotts very non-Turing Complete system which includes the stipulation that it is impossible to duplicate the code of his H, which he then violates when he creates his H1.

    In actuality, both his H and D (and their variations) just fail to meet
    the actual definition of a Program from the basic theory, being a
    specific and complete set of instructions that the algorithm uses to
    process the data provided solely by the input to the program.

    - They may abort early when a loop is structurally recognized.
    - They return a result based on runtime behavior, not semantic derivation.

    In some models:
    - SHDs may crash or refuse to decide on inputs that involve self-reference.
    - They avoid the contradiction by forbidding or failing on such cases.

    3. Why This Requires Reframing
    ------------------------------
    The classical Halting Problem assumes:
    - All programs are valid analyzable inputs.

    Which they are in the field.

    - The decider exists *outside* the execution environment.

    The decider is a seperate program. Note, in computation theory the
    programs *ARE* the execution environment. Programs are not run on
    computers, but ARE the computers, specially built for the task.

    The equivalent of the modern computer would be the UTM, where we could
    prepare the "program" and its input as the input to the UTM.

    And in this model, the UTM is given as the "Program" the decider, and
    the input is given as the input to that program.

    And the input is defined in a way that it could also be run as an input
    to the UTM on its own, with its own input.

    In others words, in te UTM model, if decider H is to decide on program P
    given input D, then we can say that

    UTM <H> <P> <D> needs to answer about the behavior of UTM <P> <D>

    Thus, H and P *ARE* defined in seperate execution environments, as we
    don't want to limit P to only be able to be run in the environment of H.


    - Deciders can analyze any encoded program as data.

    Which is the basic requirement.


    SHDs violate or restrict these assumptions:
    - Some inputs are semantically ill-formed (e.g. self-referential constructions).
    - Deciders may exist *within* the runtime framework (e.g. as part of a simulation).
    - Programs are not just strings—they may include or exclude semantic permissions.

    Reframed Problem:
    "Given a well-formed, non-self-referential program P and input x, can an
    SHD determine whether P(x) halts by simulation, within finite time?"

    This version:
    - Recognizes semantic boundaries.
    - Accepts partiality (SHDs may refuse to decide some inputs).
    - Avoids contradiction by rejecting paradox-generating constructions.

    4. Analogy to Type Theory
    --------------------------
    In modern logic systems:
    - Self-reference is blocked by stratified types or universe hierarchies.

    but what stops the copying of the code from the other level of the
    hierarchy.

    Thus FUNDAMENTALLY requries a limitation in the power of the layers.

    - Proof assistants like Coq, Agda enforce termination through typing.

    Similarly, SHDs operate with:
    - Semantic filters (not all programs are valid inputs).
    - Safety over completeness.

    This makes them useful, but outside classical universality.

    5. Practical Implication
    ------------------------
    Reframing the Halting Problem to fit SHDs allows:
    - Simulation-based analyzers to be judged on their actual utility.
    - SHDs to be integrated into verification pipelines (e.g. compilers, interpreters).
    - Clear boundaries between theoretical impossibility and practical feasibility.

    Conclusion:
    -----------
    SHDs do not contradict the Halting Problem—they bypass it by refusing to evaluate semantically ill-formed or reflexive inputs. This makes them
    partial deciders operating in a semantically filtered domain.

    To evaluate them fairly, the Halting Problem must be reframed: not as a universal challenge, but as a scoped analysis tool within a stratified or simulation-based semantic model.

    And, as pointed out, you need to answer the question of what you are
    doing to prevent the copying of algorithm from one level to another, or
    how to detect it with the ability to make unbounded variations when
    doing the copy.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to Mr Flibble on Sun May 25 11:08:22 2025
    On 2025-05-24 18:12:16 +0000, Mr Flibble said:

    On Sat, 24 May 2025 12:38:20 -0500, olcott wrote:

    My SHD refutes the classical halting problem proof that same way that
    ZFC refutes Russell's Paradox.

    ZFC Doesn’t Refute Russell’s Paradox — It Avoids It
    ZFC doesn’t show Russell’s paradox is false — it restricts the language so
    that the paradoxical construction is no longer valid.

    Likewise, your SHD does not refute the Halting Problem proof — it merely redefines the space of programs it will consider.

    More importantly, it solves another problem instead of the unsolvable one.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sun May 25 11:15:55 2025
    On 2025-05-24 18:19:54 +0000, olcott said:

    Proving that the rules have always been incoherent nonsense
    does seem to refute them.

    To say anything about refuting any rules is a category error.
    The word "refute" means to show that a claim is false. Rules
    are not claims and therefore not false.

    That you call something "incoherent nonsense" is more likely
    a consequense of your defective understanding.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sun May 25 11:21:32 2025
    On 2025-05-24 18:42:44 +0000, olcott said:

    *THIS IS AN INCOHERENT REQUIREMENT*

    int main()
    {
    DD(); // the HHH that DD calls cannot report on
    } // the behavior of its caller

    When the rules require that HHH report on the behavior
    of the direct execution of its input that requires
    HHH to report on the behavior of its caller.

    The requirement is coherent: if HHH says that DD does not halt
    and a direct execution says that DD halts then HHH does not
    meet the requirement. There is nothing ambiguous or incoherent
    there.

    --
    Mikko

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