• a computation is not allowed to report on the machine that it is embedd

    From olcott@21:1/5 to All on Thu Oct 26 13:17:29 2023
    XPost: comp.theory, sci.logic, sci.math

    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn and halts because this requires embedded_H to report on the computation
    that contains itself thus breaking the rule that all computations must
    be a pure functions of their inputs.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 11:54:07 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 11:17 AM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation
    that contains itself thus breaking the rule that all computations must
    be a pure functions of their inputs.


    Nope, by the definition of H, (and thus embedded_H)

    H WM d must go to qy if M d Halts, and to qn if M d never halts.

    Thus, BY DEFINITION embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ must go to qy if Ĥ ⟨Ĥ⟩ halts and
    to qn if it never halts, so your claim that it is not allowed to
    consider that says you are refuting that your H meets its specification,
    and thus ALL your logic is a LIE.

    Where is the "express" statement that it can not (or even allowed to
    not) consider the actual behavior of the input.

    If it is an "expresa" limitation, it will be actuall stated somewhere in
    the problem, which it isnt, so you are shown to be a LIAR.

    Care to point out the "express" statement that you get this from?

    Or, are you going to just gaslight yourself more with your Big Lie Disinformation campaign?

    Note, your refusal to quote and reply to the errors being pointed out
    just reinforce the case that you have no actual grounds to your argument
    and are admitting you have no answers to the rebuttals.

    Yes, I am in "Rebuttal" mode, because you are in "Erroneous" mode, and
    Errors need to be Rebutted. Your refusal to try a counter rebutal just
    shows your illogic.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 13:59:49 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation
    that contains itself thus breaking the rule that all computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 12:34:17 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 11:59 AM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation
    that contains itself thus breaking the rule that all computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.



    So, you don't know what the definition means, do you.

    A Computation is a pure function, which means its answer can not vary
    based on how it is "called", but only on the input it is given.

    That does not mean it isn't allowed to report on a computation that is a
    copy of a machine that includes a call to it.

    Where do you get that idea?

    Yes, you can't ask the Turing Machine that is literally asking self-referentially about the machine that is "calling" it, because it
    can't know what that is. You CAN ask about a machine that just happens
    to include a copy of the machine itself, as that doesn't actually
    "refer" to the machine, just uses a copy of it.

    I guess part of your problem is you don;t understand what a "reference"
    actual means, do you.

    Is that you you never quote the messages you are replying to, because
    you don't understand how to properly reference them?

    I guess you are just proving your utter stupidity by your incorrect
    arguments that just show how pitifully little you understand of the
    field that you are claiming to be making breakthrough arguments in.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 14:43:42 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation
    that contains itself thus breaking the rule that all computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.



    A Computation is a pure function, which means its answer can not vary
    based on how it is "called", but only on the input it is given.

    That does not mean it isn't allowed to report on a computation that is a
    copy of a machine that includes a call to it.

    All of my reviews have consistently claimed that it must report
    on the direct execution of its input and this is expressly not
    allowed because itself is contained within this direct execution.

    embedded_H is not allowed to report that
    Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 12:58:42 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 12:43 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation
    that contains itself thus breaking the rule that all computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.



    A Computation is a pure function, which means its answer can not vary
    based on how it is "called", but only on the input it is given.

    That does not mean it isn't allowed to report on a computation that is a
    copy of a machine that includes a call to it.

    Right, so why do you say it can'?


    All of my reviews have consistently claimed that it must report
    on the direct execution of its input and this is expressly not
    allowed because itself is contained within this direct execution.

    No, it is being asked about the direct execution of the program
    described by the input.

    That is a SEPERATE computation (even if identical) to the one that it is running in.


    embedded_H is not allowed to report that
    Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.


    So, you are saying it isn't allowed to give the one and only correct answer?

    Thus, YOU system is a system that is BY DEFINITION inconsistent.

    Your problem is that you have made an INCORRECT "equivalent" in your
    version that had D call the exact same copy of H as is deciding on it.

    That was explained to you YEARS ago, but you still don't seem to
    understand, that is an IMPOSSIBLE implementation of an actual Turing
    Machine, and can only be an "equivalent" if the program can't tell that
    is what is happening.

    Since your H break that information barrier, it is no longer an
    "Equivalent" of the Turing Machine H as you are claiming.

    You are just proving you don't understand what you are talking about,
    because of your utter ignorance of the topic.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 15:12:26 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation
    that contains itself thus breaking the rule that all computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 13:51:25 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 1:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation
    that contains itself thus breaking the rule that all computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    Maybe not, but it is the behavior that it is REQUIRED to decide on to be correct. If embedded_H can't actually see it, then it is just
    insufficiently powerful to do the required task (and it may be that
    NOTHING is sufficiently powerful, as the task is uncomputable).


    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    No, that logic is incorrect, It isn't asking if it will terminate
    "normally", but if it will halt, in fact.

    The fact that the copy of H inside Ĥ will abort its simulation (because
    this copy of H does, and they are copies of the same code) and return 0,
    means that Ĥ will halt.

    H needs to decide on the ACTUAL machine it sees described, not some
    imaginary "equivalent" machine that does what H is required to do to be correct.

    Your inability to understand this logic, that has been explained to you
    many times, shows your inability to understand how logic actually works,
    and what the actual definitions of the words are.

    H (and thus embedded_H) needs to respond about the ACTUAL MACHINE
    described by the input. That machine includes a copy of H that will do
    exactly what H does. That means, that for H to actually correctly decide
    the behavior of the input by simulation, H needs to be able to correctly predict its own behavior.

    Yes, THIS leads to a self-contradictory problem, but that doesn't make
    the problem "invalid", it makes in "uncomputable", because the correct
    answer exists for every possible H, its just that this H doesn't give
    that answer.

    You don't know the difference between "invalid" and "uncomputable" or "unprovable", because it seems your brain can't handle the concepts
    because of your own limitations.


    It has no idea about the behavior of the computation that
    itself is embedded within.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 16:35:55 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation
    that contains itself thus breaking the rule that all computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 16:56:33 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 2:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation >>>> that contains itself thus breaking the rule that all computations must >>>> be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    My comment, that seems to be yours because you don't quote:

    Maybe not, but it is the behavior that it is REQUIRED to decide on to be correct.


    Your responce

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    So, what else could the ACTUAL Halting question of:

    "Does the machine represented by the input to the decider Halt?"

    mean?

    Are you admitting that you think Strawman questions are valid?


    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.


    And what isn't a "pure functon of its inputs" about this?

    In particular for this question: "Does the computation represented by
    the input to the decider [namely (Ĥ) (Ĥ), which represents Ĥ (Ĥ)] halt?" Why isn't it a pure function of the input?

    Remeber Ĥ is a SPECIFIC machine input built on a SPECIFIC machine H. In
    your case, it is claimed that this SPEICIFIC H is "correct" to answer
    False (0) when run as: H (Ĥ) (Ĥ)

    And, by the structure of Ĥ, we can show that Ĥ (Ĥ), which is the
    computation described by the input, since Ĥ will use a copy of H and ask
    it what value H (Ĥ) (Ĥ) will result in, which is 0, and thus the machine
    Ĥ when applied as Ĥ (Ĥ) will halt.

    Thus, the behavior of the input (Ĥ) (Ĥ) is not dependent on anything
    other than itself.

    Note, the claimed dependency on H isn't actually there, as H's behavior
    for a given input is FIXED by the definition of H (unless you are LYING
    that H is actually a pure function). Remember the order of operations:

    1) Choose an H, which is then FIXED for the problem

    2) Build an Ĥ from that specific H

    3) Give that specific (Ĥ) (Ĥ) to that specific H, and see that it gets
    the wrong answer

    There IS a CORRECT answer to Halting (Ĥ) (Ĥ) as a mathematical function,
    as described above, thus the question is correct.

    The proof that no machine exists that can compute it show it is
    uncomputable.

    Note, just quoting the thing your are arquing about doesn't help if you
    don't actually answer the problem it points out.

    How is the requirement to answer about the actual machine described by
    the input not a requirement when it is part of the actual question.

    You are just proving you believe you don't need to actually follow the
    actual rules, which is of course, just a statment that you logic isn't
    logical.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 19:37:29 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on the computation >>>> that contains itself thus breaking the rule that all computations must >>>> be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

    So, what else could the ACTUAL
    Halting question of:
    "Does the machine represented by the
    input to the decider Halt?"

    Does D simulated by H reach it own final state?

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 17:52:31 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 5:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches >>>>> Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all computations must >>>>> be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on to
    be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

       So, what else could the ACTUAL
       Halting question of:
       "Does the machine represented by the
       input to the decider Halt?"

    Does D simulated by H reach it own final state?


    Which is only correct *IF* H meets the definition of a UTM, and actually correctly simulates its input to give the same results as the actual
    machine, that is the only thing that allows the equivalene of the actual machine and a "simulation" of the input.

    That means H can NEVER correctly say non-halting, as the UTM simulation
    doesn't end for a non-halting input, so H could never "Correctly
    Simulate" the input and also give an answer in finite time.

    Thus, YOUR definition is BY DEFINITION broken for something to actually
    be a decider.

    You can't change the meaning of the problem and still be working on the problem.

    To try to do that, just means you are working on a Strawman, and that
    proves your logic is fallacious.

    But of course, that seems to be the nature of most of your logic, which
    is why you have so much problem getting valid answers.

    You are just continuing to prove you don't understand what you are
    talking about.

    Now, you COULD ask, does the input simulated by an actual UTM reach a
    final state, as that is equivalent, but you will run into the exact same problem, H needs to determine what that UTM would do when it simulates
    the copy of H that is in the input, which will do the same thing that
    this H does.

    Or, you can just admit that you whole concept is just broken.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 20:09:10 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches >>>>> Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all computations must >>>>> be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on to
    be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

       So, what else could the ACTUAL
       Halting question of:
       "Does the machine represented by the
       input to the decider Halt?"

    Does D simulated by H reach it own final state?


    Which is only correct *IF* H meets
    the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 18:16:56 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 6:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches >>>>>> Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all computations
    must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on to
    be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


       Which is only correct *IF* H meets
       the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    And if it doesn't get to the end, it hasn't determined the actual
    behavior of the input per the problem statement.

    You don't understand that you need to use the actual definitions of the problem.

    You are just going for a Strawman, and claiming it is ok, which is just
    a LIE.


    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    Except that isn't the actual behavior of a call to the copy of itself,
    so is an INCORRECT simulation. PERIOD.

    Simulation not equal to actual behavior is an ERROR. DEFINITION.


    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.

    So, ALL H's will either stop their simulation or not.

    If it doesn't, then H never answers.

    If it does, then a correct simulation of the input needs to account for
    that, which your algorithm doesn'r.

    You are just asserting that it is ok you use FALSE premises in your logic,

    Thus your logic is unsound.

    You are just asserting a Strawman argument, and FAILING.

    You seem to believe that wrong answers can be right, which means you
    believe it is ok to have a logic system built on contradictions.

    This shows that you don't understand how logic works, but you just want
    to work with the Big Lie and just pass your Disinformation to try to
    press your unsound agenda.

    You are just proving you are nothing but an ignorant liar.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 20:28:04 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches >>>>>> Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all computations
    must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to
    be a pure function of their inputs no Turing Machine is allowed to
    report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on to
    be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


       Which is only correct *IF* H meets
       the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 18:36:45 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 6:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all computations >>>>>>> must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on
    to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM



    On what grounds do you say that?

    By the definition of the problem, H must report if the machine
    represented by its input will Halt. PERIOD.

    It can use an actually "equivalent" criteria, but it must be actually equivalent.

    Thus, you claim otherwise just shows that you think "Strawmen" criteria
    are valid logical argument.

    You CLEARLY don't understand what is meant by REQUIREMENTS, because your
    mind just don't understand the nature of Logic or Truth.

    On what grounds is H allowed to give an answer that isn't actually the
    answer to the question it is requried to be answering?

    You are just admitting that you are just a liar, and that you totally
    don't understand what you are talking about.

    It really does seem that you think LIES are perfectly fine logic, just
    like the BIG LIE you have been telling with your Disinformation campaign
    that you are engaging in to supposedly fight disinformation.

    PURE HYPOCRACY.

    There is a place in HELL reserved just for you, which is why you refuse
    to look at what is True, because the truth of your future is just to
    horrible to look at.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 21:04:17 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all computations >>>>>>> must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on
    to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    "On what grounds do you say that?"

    Those ARE the states that H sees.

    If the definition of the problem says it must
    look at the computation that contains itself
    then this definition of the problem is AFU!

    We can know that definitions are incorrect
    when two of them contradict each other.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 19:26:29 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 7:04 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly >>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>>>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on
    to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    "On what grounds do you say that?"

    Those ARE the states that H sees.

    But not the question that H NEEDS to answer!

    You seem to be saying that a correct answer to "how many cats do you
    have?" would be "I have 2 dog." even though it doesn't actually answer
    the question asked.


    If the definition of the problem says it must
    look at the computation that contains itself
    then this definition of the problem is AFU!


    Nope. It doesn't matter that this instance happens to have a copy of itself.

    Note, the input can't actually reference the decider that the input is
    being given to, as that wouldn't be a computation.

    It CAN use a copy of a specific machine, and that can be the machine we
    happen to give it to.

    That just says that the mathematics is powerful enough to express this
    sort of relationship.

    Your not understanding this just means that YOU are AFU.

    We can know that definitions are incorrect
    when two of them contradict each other.


    Nope.

    There IS a correct answer, so the question is NOT incorrect.

    Since the H that you claim to be correct answer False for H (Ĥ) (Ĥ), we
    know that with Ĥ built from this H, Ĥ (Ĥ) will Halt, and thus the
    CORRECT answer to the question is True, the computation described by the
    input will Halt. Thus there is no "contradiction" in the problem.

    The fact that no H can give this correct answer for the Ĥ built on it,
    means the problem is uncomputable, which is a perfectly valid answer.

    Your mind just doesn't seem to understand this simple fact, because your "correct reasoning" system is just too simple. The world needs logic
    bigger than the toy system you want to try to use, so your mind just
    seems to overload.

    You don't get to just try to define real problems as "invalid" because
    they cause problems for your logic system (or your tiny mind).

    Admit it, your logic is just broken.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 21:48:21 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all computations >>>>>>> must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on
    to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Thu Oct 26 23:04:31 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly >>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>>>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on
    to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to look
    at "itself" but at something that just happens to be copy of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues* *to call embedded_H in recursive simulation until embedded_H stops it*

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 20:17:05 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 7:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly >>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts. >>>>>>
    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on
    to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to look
    at "itself" but at something that just happens to be copy of itself.

    There is no rule against looking at an input that just happens to be a
    copy of itself, that if a figment of your own mind, the rule you seem to
    be referencing is about its inability to know how it is being used.

    You just don't understand what you are talking about, and are just
    making up rules by twisting things, because you are so ignorant.

    You don't seem to understand that you can freely make copyies of Turing Machines, and Turing Machines can easily be given representations of
    Turing Machines, including themselves.

    In fact, it turns out that it is impossible for a given Turing Machine
    to identify that an input is a representation of itself. (It might be
    able to recognize a finite number of representations of itself, but not
    all).

    THis of course, totally breaks your method, as it turns out that your H
    can't ever detect that Ĥ is using a copy of itself to try to do your logic.

    Of course, you don't understand what that means, as you can't write even
    a fairly simple Turing machine, because they are too complicated for you.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Oct 26 21:45:27 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/23 9:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly >>>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>> same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on >>>>>> to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to look
    at "itself" but at something that just happens to be copy of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues* *to call embedded_H in recursive simulation until embedded_H stops it*


    No, it is NOT forbidden.

    Literally ANY machine can be asked to look at the input (Ĥ) (Ĥ) and for
    a halt decider, that means look at the behavior of the computation Ĥ (Ĥ).

    There is not problem with this.

    Yes, if some H / embedded_H just continues to simulate, then that H will
    never answer, and thus FAIL to be a decider.

    But THIS H doesn't do that, it DOES abort, and thus the actual behavior
    of Ĥ (Ĥ) is to reach a Halt State, so the correct answer is Halting.

    You are using unsound logic when you think that one copy of H/embedded_H
    gets stuck in an infinte loop while another doesn't.

    If you care to disagree, please show the ACTUAL CODE for an H where the
    "outer" H aborts its simulation and returns an answer, but the actual
    running or actual correct simulation (i.e. one that never aborts) of the
    Ĥ built on that EXACT same code gets stuck in the loop.

    Remember, BOTH COPY of H, even the one you are calling "embedded_H" must
    be the copies of the exact same code.

    To do so, H must not actually be a "computation" as its behavior is
    based on more than its explicit input, and thus it can't be the
    equivalent of a Turing Machine.

    You are just proving your stupidity and ignorance of what you are
    talking about.

    You keep on saying that doing the requirments are some how forbidden,
    but can't actually quote an actual rule that actually say so, but are conflating that the program being decided on can't make a request about
    the decider that is currently deciding on it, but CAN use a copy of a
    specific decider.

    Thus it is ALLOWS for a specific Ĥ to use a specific H, and then even if
    we use an equivalent H (or the exact same one) that is allowed.

    What we can't do is have a specific Ĥ that tries to use whatever Hi is
    trying to decide it at the moment, it needs to choose what Hi, now
    called H, it will be based on.

    That particular Ĥ will only confound some of the Hi, only those that
    happen to agree with H what H (Ĥ) (Ĥ) computed to, which was the wrong answer.

    The key is that for ANY Hi, we can create a specific Ĥi (different from
    all other Ĥj) based on THAT Hi, that will confound that particular Hi.
    Thus every Hi has a Ĥi that confounds it, so no Hi can corectly decide
    all inputs.

    The question is still correct, as there IS a correct answer for every
    input (Ĥi) (Ĥi), which just happens (by construction) to be the opposite
    of what Hi (Ĥi) (Ĥi) produces.

    This is like above your head, and I suspect you will come back with
    another stupid reply, but if you don't actually point out an error, I
    can just point back to this and say you are too stupid to understand.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 09:26:51 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the
    computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly >>>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>> same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide on >>>>>> to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to look
    at "itself" but at something that just happens to be copy of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues* *to call embedded_H in recursive simulation until embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 07:51:33 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 7:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the >>>>>>>>>> computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly >>>>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>> same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide
    on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information. >>>>>

    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to
    look at "itself" but at something that just happens to be copy of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues* >> *to call embedded_H in recursive simulation until embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.


    Yes, No computation has the ability to know if, or what, computation it
    is contained in, and it is also impossible to write a program whose
    behavior is dependent on (or if) its description is being decided on.

    This is because, in part, that Turing Machines can't "reference" another
    Turing Machine, they can only be given a copy of a description of it.

    This does NOT mean that you can't give a machine an input that just
    happens to contains a copy of the description of that machine or a
    machine that contains it.

    There is nothing in the concept of a "Pure Function" that prohibits
    about asking a decider about a specified program given as an input, even
    if that specified program happens to include a copy of the decider, or a
    copy of a program that contains a copy of that decider.

    You can not ask it about the specified only by reference "The program
    that is containing this copy". It isn't that the program itself can't be
    asked about, it just can't be asked about via a "pronoun-like" reference.

    Your repeating your INCORRECT claim just shows how ignorant you are of
    the actual "rules" of the game you are making grand FALSE claims about.
    This has been explained to you MANY times, and your repeating your lies
    just shows how STUPID you are.

    I note again, that you haven't responded to ANY of the errors pointed
    out in your argument, but you just repeat your erroneous statement,
    because you KNOW that it is incorrect and you have no reply to the
    errors pointed out, but just want to repeat your 'Big Lie' as part of
    your Disinformation campaign because you can't face the actual truth of
    the matter.

    You are just sick in the head, and have gas-lighted yourself into being
    a pathological lying idiot.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 10:05:18 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the >>>>>>>>>> computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all computations to >>>>>>>>> be a pure function of their inputs no Turing Machine is allowed to >>>>>>>>> report on the computation that itself is contained within.

    This utterly forbids embedded_H from reporting that the directly >>>>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>> same machine with the exact same input, recursively such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide
    on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information. >>>>>

    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to
    look at "itself" but at something that just happens to be copy of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues* >> *to call embedded_H in recursive simulation until embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 08:32:11 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 8:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the >>>>>>>>>>> computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all
    computations to
    be a pure function of their inputs no Turing Machine is
    allowed to
    report on the computation that itself is contained within. >>>>>>>>>>
    This utterly forbids embedded_H from reporting that the directly >>>>>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide >>>>>>>> on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information. >>>>>>

    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to
    look at "itself" but at something that just happens to be copy of
    itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues*
    *to call embedded_H in recursive simulation until embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.


    Why do you think this FALSE fact?

    In can most certainly base its decision on the behavior of the
    computation Ĥ (Ĥ) if (Ĥ) (Ĥ) is given as an input, and in fact it MUST.

    What is can't do is handle a question like: "What is the behavior of the program that is calling you?",

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    No, I don't agree to the first part, when stated the way you do.


    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.


    No, I use those terms because YOU first used them on me, and you have
    proven that the description appies to YOU.

    YOU are continuing to prove your utter stupidity by just repeating your INCORRECT claims and not actually responding to the errors pointed out.

    It seems you don't even understand the proper use of simple English words.

    You ARE a totally ignorant hyporitical pathological lying idiot, as demonstrated by your behavior.

    If you want me to stop calling you that, GROW UP and respond properly,
    actually QUOTE the part where I point out EACH of your errors and
    address the point I make and show where it is wrong.

    You of course can't do that, because what I am saying is correct, and
    you have no actual arguement against it, so YOU resort to "ad hominem",
    trying to refute the argument I give by the fact that after proving you
    wrong, I use your repeated lies as a proof of your lack of veracity.

    The fact is, you are totally incompetent in the field, but are just a
    legend in your own mind.

    You like to quote "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer

    In your case Idiocy shoots at a target that isn't there.

    It is clear that you do not understand what you are doing and have
    gas-light yourself into believing your own lies. You have convinced
    yourself, that you, a person with no training in the field are smarter
    that the experts that have worked in it all their lives. On measure of intelligence is how well you know what you know. You fail at this test.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 10:57:30 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the >>>>>>>>>>> computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all
    computations to
    be a pure function of their inputs no Turing Machine is
    allowed to
    report on the computation that itself is contained within. >>>>>>>>>>
    This utterly forbids embedded_H from reporting that the directly >>>>>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide >>>>>>>> on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information. >>>>>>

    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to
    look at "itself" but at something that just happens to be copy of
    itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues*
    *to call embedded_H in recursive simulation until embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 09:14:03 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 8:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the >>>>>>>>>>>> computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all
    computations to
    be a pure function of their inputs no Turing Machine is
    allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the directly >>>>>>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>
    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide >>>>>>>>> on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information. >>>>>>>

    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to
    look at "itself" but at something that just happens to be copy of
    itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and >>>> this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues*
    *to call embedded_H in recursive simulation until embedded_H stops it* >>>>

    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    Because it doesn't know how to CORRECTLY simulate its input.

    It still NEEDS (to be correct) to answer the problem as given, "Does the computation described by the input halt in a finite number of steps?"

    Just because it can't actually compute that answer, doesn't mean the
    answer doesn't exist. The problem is VALID, it is just UNCOMPUTABLE.


    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    No, it doesn't. It has been programmed to do so in that case, but as
    has. been shown, that is an incorrect operation. Programs don't "know"
    in the sense that people do. That is one of your category errors.

    And it doesn't matter if the simulated embedded_H hasn't done anything
    about it yet, the fact is that the machine being simulated WILL do
    exactly the same thing that this copy of it does.

    The simulation isn't the "reality" of the input, that is based on the
    actual operation of the machine described, or a COMPLETE and CORRECT
    simulation of that input (one that is never aborted, and thus not the
    one done by H).


    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.


    Right, a DIFFERENT embedded_H, built on a DIFFERENT H, when given a
    DIFFERENT (Ĥ) (Ĥ) [different because it is built on the different H, and
    any given Ĥ is built on a specific H] when run goes into an infinite
    recursion loop.

    But if we make a new H, that is changed in that way and give it this
    input, the it will see Ĥ call the original H and that H simulate its
    input and then abort its input and return non-halting and then Ĥ will halt.

    That CORRECT simulation is the one and only CORRECT simulation of the
    input, and thus proves that the correct answer is HALTING.

    You are just proving you don't understand that basics of what programs
    are, and somehow think that a partial simulation of a program defines
    the behavior of that program even if it is different then the actual
    behavior of the program.

    You don't seem to understand that programs, to be correct, must obey
    their requirements, and you aren't allowed to just change them because
    you can't find a solution that meets them.

    You don't seem to understand that it is just a fact that some VALID
    functions are just uncomputable, and no program is ever going to be able
    to correctly compute all the points on it.

    This is because you are just too STUPID to understand how logic actually
    works.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 12:16:44 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the >>>>>>>>>>>> computation
    that contains itself thus breaking the rule that all
    computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all
    computations to
    be a pure function of their inputs no Turing Machine is
    allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the directly >>>>>>>>>>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>
    It has no idea about the behavior of the computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to decide >>>>>>>>> on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace information. >>>>>>>

    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to
    look at "itself" but at something that just happens to be copy of
    itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and >>>> this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues*
    *to call embedded_H in recursive simulation until embedded_H stops it* >>>>

    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 12:20:45 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the >>>>>>>>>>>>> computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all
    computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and >>>>>>>>>>>> halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to
    decide on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace
    information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to
    look at "itself" but at something that just happens to be copy of
    itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and >>>>> this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it
    continues*
    *to call embedded_H in recursive simulation until embedded_H stops it* >>>>>

    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06 int Halt_Status = H(x, x);
    07 if (Halt_Status)
    08 HERE: goto HERE;
    09 return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14 H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06
    to its own final state at line 09.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 10:43:43 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 10:16 AM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on the >>>>>>>>>>>>> computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all
    computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and >>>>>>>>>>>> halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to
    decide on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive
    properties.

    Nothing is computable that is not a pure function of its
    inputs and the behavior of the computation that a decider
    is contained within is absolutely not a pure function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace
    information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to
    look at "itself" but at something that just happens to be copy of
    itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and >>>>> this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it
    continues*
    *to call embedded_H in recursive simulation until embedded_H stops it* >>>>>

    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    The actual sequence of state transitions that happens when we actually
    run the program described by the input, or created by a UTM which BY
    DEFINITON exactly recreates this, and thus doesn't stop before reaching
    the end is a "CORRECT SIMULTION"

    Since H doesn't do that, it is doing an INCORECT simulation PERIOD.

    Do you agree that your H doesn't actually continue its simulation till
    it reaches the end?

    BY DEFINITION, anything less than that is a INCORRECT SIMULATION, for
    the purpose of a Halt Decider.

    So, you claim that H can stop and still be correct is just a
    contradiction, and a LIE.

    You just don't understand what it means to be "Correct"

    If someone put only 75% of the parts on your car, have they correctly
    assembled it? Even if every part they did put on was in the right place?

    Of course not.

    So a partial simulation is not a Correct Simulation, despite how much
    you want to try to convince yourself that it is.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 10:57:01 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 10:20 AM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on >>>>>>>>>>>>>> the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all
    computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and >>>>>>>>>>>>> halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace
    information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to >>>>>> look at "itself" but at something that just happens to be copy of
    itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and >>>>>> this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it
    continues*
    *to call embedded_H in recursive simulation until embedded_H stops >>>>>> it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)

    Note your "unless aborted" shows a deception.

    You have defined your H, and your H does abort, so the "unless aborted"
    because a falsehood.

    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06
    to its own final state at line 09.


    So, you are just repeating your ignorant lie that you don't understand
    what a program actually is and how programs work. We can't talk abut
    'unless" when talking about a specific program. It DOES or it DOESN'T.

    A "Set of Programs" is not a "Program" and confusing them is just a
    stupid category error.

    Your logic is just faulty.

    The ACTUAL correct simulation is that main invokes H(D,D), which
    simulated D(D) which is simulated to call H(D,D) which will simulate the simulation until it sees this calling H(D,D) again, and then it aborts
    its simulation and returns non-halting to the simulted D(D) which is
    then simulated to halting.

    You "Simultation Invariant" is just a Red Herring, because it doesn't
    actually refer to the actual input.

    There is only ONE "H" in view in the actual problem, and only one "D" in
    view. That H doesn't "correctly simulate" its input, since it aborts it prematurly, so the invariant is actually a false premise (since H
    doesn't correctly simulate its input).

    When applied to the whole set, item by item, we see that every H that
    answers, has invaldated the invariant by aborting its simulation, and
    any H that tries to keep the invariant, doesn't answer.

    All you have done is proved that no H/D pair by this method, creates a D
    that H can prove is Halting. And that if it reports non-halting, it
    broke the invariant, and thus is wrong, and if it doesn't abort, it
    fails to answer and thus doesn't meet the requirements, and thus is wrong.

    So, you are just supporting the theorem that there does not exist any
    decider that can correctly decide for all possible computation inputs,
    as there is a specific input for every decider that it will fail on.

    That doesn not make the quesition invalid, as every question had a
    correct answer, it is just that H failed to give it. Thus the problem is uncomputable, which is a valid result.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 12:59:31 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ >>>>>>>>>>>>>> reaches Ĥ.qn
    and halts because this requires embedded_H to report on >>>>>>>>>>>>>> the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all
    computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and >>>>>>>>>>>>> halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere
    will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace
    information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need to >>>>>> look at "itself" but at something that just happens to be copy of
    itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and >>>>>> this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it
    continues*
    *to call embedded_H in recursive simulation until embedded_H stops >>>>>> it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 11:27:00 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 10:59 AM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to >>>>>>>>>>>>>>> ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ >>>>>>>>>>>>>>> ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on >>>>>>>>>>>>>>> the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and >>>>>>>>>>>>>> halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace
    information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need
    to look at "itself" but at something that just happens to be copy >>>>>>> of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and >>>>>>> this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H
    stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


    Then H isn't a Halt Decier. PERIOD.

    Because the behavior described by the input to a Halt Decider is the
    sequence of state transitions that happes when you actually run the
    program described by the input.

    Note, "Behavior of the Input" for a decider is NOT what the decider does
    with the input, but what the problem describes as the behavior to be
    decided on.

    So, you are just proving you don't know what you are talking about.

    In fact, a problem CAN'T talk about what behavior the decider actually
    does, as the decider doesn't exist yet when the problem is stated, so
    the problem describes the behavior to be decided on, and then the
    programmer has the task to figure out how to do it.

    If we CAN just simulate that behavior in a finite number of steps, then
    the program can clearly be written. The interesting challanges occur
    when you can't directly do that. Sometimes you can validly transform
    that simulation to something that can be done and thus solve a problem
    that at first seems unsolvable (perhaps you find an induction property
    that can reduce an infinite operation to a finite operation). Sometimes
    you just need to accept that you can't figure out how to compute the
    answer in finite time. Sometimes it can be shown that you can't actually
    ever do it.

    You clearly don't understand the meaning of the words you use, and since
    you claim otherwise, you are just lying, and stupdid to think people
    can't tell it.

    You may have had some interesting ideas, but you have poisoned your name
    by your idiotic claims that you should know better about.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 13:41:27 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied to >>>>>>>>>>>>>>> ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ >>>>>>>>>>>>>>> ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on >>>>>>>>>>>>>>> the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and >>>>>>>>>>>>>> halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact >>>>>>>>>>>>> same machine with the exact same input, recursively such that >>>>>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the
    incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace
    information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need
    to look at "itself" but at something that just happens to be copy >>>>>>> of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and >>>>>>> this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H
    stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


    Then H isn't a Halt Decier. PERIOD.

    Because the behavior described by
    the input to a Halt Decider is the
    sequence of state transitions that
    happes when you actually run the program
    described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) { return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 12:07:40 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 11:41 AM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied >>>>>>>>>>>>>>>> to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ >>>>>>>>>>>>>>>> ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on >>>>>>>>>>>>>>>> the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and
    halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that >>>>>>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace
    information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need >>>>>>>> to look at "itself" but at something that just happens to be
    copy of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H
    stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


       Then H isn't a Halt Decier. PERIOD.

       Because the behavior described by
       the input to a Halt Decider is the
       sequence of state transitions that
       happes when you actually run the program
       described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    No, I said you can't ask H/embedded_H about "the program that is
    calling/using it".

    I.E., you can provide a program to be looked at by giving a DESCRIPTION
    of it, but not by trying to for a reference based on the decider that
    happens to be trying to decide.

    This is the difference between saying:

    "Tell me if the program decribed by (Ĥ) (Ĥ) halts?" which is a proper question and

    "Tell me if the program that is calling you will Halt?" which is not,
    because that isn't a proper "description" of the program to be decided
    (even if it is a English language descriptio) because the description
    isn't fully descriptive as it needs context.

    You just don't seem to understand the difference between these, likely
    because you don't understand how to properly handle abstractions.


    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    But it is asked to decide on a COPY of the machine REPRESENTED by the
    input, not the "computation that itself is containd within"


    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


    Right, because it wasn't given 5 and 6, but 3 and 4.

    In the same way, H was given (Ĥ) (Ĥ) so it needs to decide on that.

    H (Ĥ) (Ĥ) isn't allowed to try to decide on H' (H') (where H' is a
    program built on an H1 that doesn't abort its simulation, but needs to
    actually decide on Ĥ (Ĥ) where Ĥ is built on the H that does exactly
    what the H you are claiming to be correct does, which is abort its
    simulaiton (because it INCORRECTLY decides that the input is non-halting).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 14:24:18 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied >>>>>>>>>>>>>>>> to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ >>>>>>>>>>>>>>>> ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on >>>>>>>>>>>>>>>> the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and
    halts.

    That is <not> the behavior that embedded_H sees.

    When embedded_H is a pure function of its inputs then it sees >>>>>>>>>>>>>> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such that >>>>>>>>>>>>>> the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence
    of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace
    information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need >>>>>>>> to look at "itself" but at something that just happens to be
    copy of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H
    stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
    of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


       Then H isn't a Halt Decier. PERIOD.

       Because the behavior described by
       the input to a Halt Decider is the
       sequence of state transitions that
       happes when you actually run the program
       described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


    No, I said you can't ask H/embedded_H
    about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 13:20:56 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 12:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied >>>>>>>>>>>>>>>>> to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ >>>>>>>>>>>>>>>>> ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on >>>>>>>>>>>>>>>>> the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn >>>>>>>>>>>>>>>> and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then it >>>>>>>>>>>>>>> sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such >>>>>>>>>>>>>>> that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace >>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need >>>>>>>>> to look at "itself" but at something that just happens to be >>>>>>>>> copy of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H >>>>>>>>> stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


       No, I said you can't ask H/embedded_H
       about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    Yes we can.

    My FULL comment was:

    No, I said you can't ask H/embedded_H about "the program that is calling/using it".

    I.E., you can provide a program to be looked at by giving a DESCRIPTION of it, but not by trying to for a reference based on the decider that happens to be trying to decide.

    This is the difference between saying:

    "Tell me if the program decribed by (Ĥ) (Ĥ) halts?" which is a proper question and

    "Tell me if the program that is calling you will Halt?" which is not, because that isn't a proper "description" of the program to be decided (even if it is a English language descriptio) because the description isn't fully descriptive as it needs
    context.

    You just don't seem to understand the difference between these, likely because you don't understand how to properly handle abstractions.


    Note, you can ask about ANY program that you provide the representation
    of. What you can't do is "refer" to a program indirectly via what the
    decider is or what is calling it, because a Turing Machine, by its
    definition (which is what the input is describing effectively) can't
    detect who is looking at it.

    You have been told this, and have never actually shown why it isn't
    true, but you just ignore this FACT, and repeat your LIE.

    Face it, you just don't know what you are talking about, because you are
    just ignorant of the field, apperently INTENTIONALLY so, as you were
    afraid that knowledge of the field would just "brainwash" you into false
    ideas, when in actuality it would show you how it actually works,

    You seem to be afraid of the truth, perhaps because you native language
    is just lies.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 15:31:50 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf

    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied >>>>>>>>>>>>>>>>> to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ >>>>>>>>>>>>>>>>> ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report on >>>>>>>>>>>>>>>>> the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn >>>>>>>>>>>>>>>> and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then it >>>>>>>>>>>>>>> sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
    same machine with the exact same input, recursively such >>>>>>>>>>>>>>> that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of
    itself that will never stop copying and calling other
    copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace >>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H need >>>>>>>>> to look at "itself" but at something that just happens to be >>>>>>>>> copy of itself.

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

    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H >>>>>>>>> stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


       No, I said you can't ask H/embedded_H
       about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 13:48:39 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 1:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied >>>>>>>>>>>>>>>>>> to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ >>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report >>>>>>>>>>>>>>>>>> on the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn >>>>>>>>>>>>>>>>> and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then it >>>>>>>>>>>>>>>> sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the >>>>>>>>>>>>>>>> exact
    same machine with the exact same input, recursively such >>>>>>>>>>>>>>>> that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of >>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace >>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>> need to look at "itself" but at something that just happens to >>>>>>>>>> be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H >>>>>>>>>> stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may. >>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions >>>>>> that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>
    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06 >>>>> to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    Except that it CAN be the input too.

    What else is the input to H(D,D)?

    That MUST be D(D), or H isn't a Halt Decider.

    You can't try to have it both ways.

    If you can't ask H about the program D(D), then you are just admitting
    that you H isn't actually a Halt Decider, as a Halt Decider must answer
    about *ANY* program, and D is a VALID program.


    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    Right, which is what a UTM given that same input would do.

    PERIOD.

    Anything else is a LIE.

    Note, it is your H that "ignores" instructions, as it some how concludes
    that a call to H(D,D) will never return when it does return a 0.

    Thus, H's "simulation" is NOT CORRECT.

    It is your FALSE assumption that this call goes forever, but that is
    because your H doesn't see H as the program it is, but a different
    program that it imagines, and thus it is WRONG.

    You are just proving your ignorance of the subject and your ignorance of
    how logic works.

    You prove this by your utter refusal to try to point out an actual
    errors in what I say referencing any actual principle of the field (in
    part because you don't know the field, so you can't reference something
    you don't know).

    Formal Logic Systems have RULES, and to be in it, you need to follow the
    rules.

    Claiming to talk about a theorem is a Formal Logic System means
    accepting the rules of that system, so you need to follow them.

    You don't, so everything you say becomes invalid.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 16:08:22 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is applied >>>>>>>>>>>>>>>>>> to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that Ĥ >>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report >>>>>>>>>>>>>>>>>> on the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine is >>>>>>>>>>>>>>>>> allowed to
    report on the computation that itself is contained within. >>>>>>>>>>>>>>>>>
    This utterly forbids embedded_H from reporting that the >>>>>>>>>>>>>>>>> directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn >>>>>>>>>>>>>>>>> and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then it >>>>>>>>>>>>>>>> sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the >>>>>>>>>>>>>>>> exact
    same machine with the exact same input, recursively such >>>>>>>>>>>>>>>> that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of >>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace >>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>> need to look at "itself" but at something that just happens to >>>>>>>>>> be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H >>>>>>>>>> stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may. >>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions >>>>>> that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>
    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06 >>>>> to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 14:17:59 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 2:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that >>>>>>>>>>>>>>>>>>> Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report >>>>>>>>>>>>>>>>>>> on the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine >>>>>>>>>>>>>>>>>> is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting that >>>>>>>>>>>>>>>>>> the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn >>>>>>>>>>>>>>>>>> and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then >>>>>>>>>>>>>>>>> it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the >>>>>>>>>>>>>>>>> exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of >>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace >>>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>>> need to look at "itself" but at something that just happens >>>>>>>>>>> to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at >>>>>>>>>>> and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H >>>>>>>>>>> stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution >>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may. >>>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions >>>>>>> that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>>
    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06 >>>>>> to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    But the input CAN be the string that represents the program, just as ALL
    inputs are specifed.

    For you x86 program version, it could be the x86 assembly byte code for
    the FULL program, with starting address, or the source code for the FULL program (if H includes a compiler) or any of number of methods of
    representing it.

    Note, H isn't the "process" that is executing, that is just an instance
    of H, H is the codebase of that process.

    Are you really are that stupid, or is it just an act to try to avoid the obvious errors you are making.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 16:27:14 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 4:16 PM, olcott wrote:
    On 10/27/2023 4:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2 >>>>>>>>>>>>>>>>>>>>
    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that >>>>>>>>>>>>>>>>>>>> Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report >>>>>>>>>>>>>>>>>>>> on the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine >>>>>>>>>>>>>>>>>>> is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting that >>>>>>>>>>>>>>>>>>> the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn
    and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then >>>>>>>>>>>>>>>>>> it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the >>>>>>>>>>>>>>>>>> exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED >>>>>>>>>>>>>>>>> to decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state? >>>>>>>>>>>>>>>>

        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of >>>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace >>>>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input >>>>>>>>>>>>> and another definition of computation says that:
    (B) H is not allowed to look at the computation that >>>>>>>>>>>>> contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>>>> need to look at "itself" but at something that just happens >>>>>>>>>>>> to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked >>>>>>>>>>>> at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H >>>>>>>>>>>> stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution >>>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second >>>>>>>>>> part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may. >>>>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call >>>>>>>>> the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive >>>>>>>>> simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input." >>>>>>>>
    When a TM simply simulates the actual sequence of state transitions >>>>>>>> that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>> 03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>>>
    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own
    line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    "But the input CAN be the string
     that represents the program"

    That input program does specify the sequence of instructions
    that the above source-code shows. This sequence does show that D
    does call H in recursive simulation until H aborts this simulation.



    And it shows that THAT H will abort its simulation and return 0 to D and
    D will Halt.

    Remember, it is ALL the code, including every subroutine called, which
    includs H, the PARTICULAR H that this D was built on, not any other.

    That fact that it doesn't return until the H that is called aborts
    another copy of this simulation is irreverent, that is just part of the algorithm within the program D, H DOES return, and D does Halt.

    You still don't seem to understand this nature of a program, because you
    are too stupid.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 18:16:10 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 4:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that >>>>>>>>>>>>>>>>>>> Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report >>>>>>>>>>>>>>>>>>> on the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine >>>>>>>>>>>>>>>>>> is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting that >>>>>>>>>>>>>>>>>> the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn >>>>>>>>>>>>>>>>>> and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then >>>>>>>>>>>>>>>>> it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the >>>>>>>>>>>>>>>>> exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED to >>>>>>>>>>>>>>>> decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state?


        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of >>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace >>>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input
    and another definition of computation says that:
    (B) H is not allowed to look at the computation that
    contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>>> need to look at "itself" but at something that just happens >>>>>>>>>>> to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at >>>>>>>>>>> and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H >>>>>>>>>>> stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution >>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second
    part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may. >>>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
    the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive
    simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input."

    When a TM simply simulates the actual sequence of state transitions >>>>>>> that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
    03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>>
    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 06 >>>>>> to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    "But the input CAN be the string
    that represents the program"

    That input program does specify the sequence of instructions
    that the above source-code shows. This sequence does show that D
    does call H in recursive simulation until H aborts this simulation.



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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 20:03:43 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 6:16 PM, olcott wrote:
    On 10/27/2023 4:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2 >>>>>>>>>>>>>>>>>>>>
    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider that >>>>>>>>>>>>>>>>>>>> Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to report >>>>>>>>>>>>>>>>>>>> on the computation
    that contains itself thus breaking the rule that all >>>>>>>>>>>>>>>>>>>> computations must
    be a pure functions of their inputs.


    By the definition of computation that requires all >>>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine >>>>>>>>>>>>>>>>>>> is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting that >>>>>>>>>>>>>>>>>>> the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn
    and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then >>>>>>>>>>>>>>>>>> it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call the >>>>>>>>>>>>>>>>>> exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation that >>>>>>>>>>>>>>>>>> itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED >>>>>>>>>>>>>>>>> to decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state? >>>>>>>>>>>>>>>>

        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of >>>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description
    (b) The outermost H always has the most execution trace >>>>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input >>>>>>>>>>>>> and another definition of computation says that:
    (B) H is not allowed to look at the computation that >>>>>>>>>>>>> contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>>>> need to look at "itself" but at something that just happens >>>>>>>>>>>> to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked >>>>>>>>>>>> at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it >>>>>>>>>>>> continues*
    *to call embedded_H in recursive simulation until embedded_H >>>>>>>>>>>> stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not>
    its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its
    halt status decision on the behavior of the direct execution >>>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second >>>>>>>>>> part that <is> a necessary consequence of the first part.

    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick
    with the objective facts and let the chips fall where they may. >>>>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not
    the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call >>>>>>>>> the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive >>>>>>>>> simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input." >>>>>>>>
    When a TM simply simulates the actual sequence of state transitions >>>>>>>> that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>> 03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>>>
    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own
    line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    "But the input CAN be the string
     that represents the program"

    That input program does specify the sequence of instructions
    that the above source-code shows. This sequence does show that D
    does call H in recursive simulation until H aborts this simulation.

    "And it shows that THAT H will abort its simulation and return 0 to D"

    It can't possibly do that because you insist that it is only allowed
    to report on the behavior after it does that and it doesn't do that
    after it has already done that.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 18:36:16 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 6:03 PM, olcott wrote:
    On 10/27/2023 6:16 PM, olcott wrote:
    On 10/27/2023 4:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2 >>>>>>>>>>>>>>>>>>>>>
    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider >>>>>>>>>>>>>>>>>>>>> that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to >>>>>>>>>>>>>>>>>>>>> report on the computation
    that contains itself thus breaking the rule that >>>>>>>>>>>>>>>>>>>>> all computations must
    be a pure functions of their inputs. >>>>>>>>>>>>>>>>>>>>>

    By the definition of computation that requires all >>>>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine >>>>>>>>>>>>>>>>>>>> is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting that >>>>>>>>>>>>>>>>>>>> the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of >>>>>>>>>>>>>>>>>>>> Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then >>>>>>>>>>>>>>>>>>> it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call >>>>>>>>>>>>>>>>>>> the exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation >>>>>>>>>>>>>>>>>>> that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED >>>>>>>>>>>>>>>>>> to decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state? >>>>>>>>>>>>>>>>>

        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of >>>>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description >>>>>>>>>>>>>>>> (b) The outermost H always has the most execution trace >>>>>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input >>>>>>>>>>>>>> and another definition of computation says that:
    (B) H is not allowed to look at the computation that >>>>>>>>>>>>>> contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>>>>> need to look at "itself" but at something that just happens >>>>>>>>>>>>> to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked >>>>>>>>>>>>> at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how >>>>>>>>>>>>> it continues*
    *to call embedded_H in recursive simulation until
    embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not> >>>>>>>>>>>> its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its >>>>>>>>>>> halt status decision on the behavior of the direct execution >>>>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second >>>>>>>>>>> part that <is> a necessary consequence of the first part. >>>>>>>>>>>
    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick >>>>>>>>>>> with the objective facts and let the chips fall where they may. >>>>>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not >>>>>>>>>> the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call >>>>>>>>>> the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive >>>>>>>>>> simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input." >>>>>>>>>
    When a TM simply simulates the actual sequence of state
    transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>>> 03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates >>>>>>>> D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own
    line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    "But the input CAN be the string
      that represents the program"

    That input program does specify the sequence of instructions
    that the above source-code shows. This sequence does show that D
    does call H in recursive simulation until H aborts this simulation.

    "And it shows that THAT H will abort its simulation and return 0 to D"

    It can't possibly do that because you insist that it is only allowed
    to report on the behavior after it does that and it doesn't do that
    after it has already done that.


    H must report on the FULL behavior of the input. Just because you can't
    get the right answer in H, doesn't mean the problem is incorrect, just
    that it is uncomputable. The fact that H can't simulate far enough to
    know the answer is just a hint that uncomputable is a likely answer.

    YOU need to decide what algorithm you are going to use, (and "get the
    right answer isn't an algorithm).

    We have already determined that if you chose an H that keeps on
    simulating until it ACTUALLY has determined the answer, then, because
    then D is built on that same H, H WILL get stuck in an infinite
    simulation recursion and never give an answer.

    If you decide on the other hand, that your H will give up simulating at
    some point, so it can give an answer and at least be a decider, then we
    need to admit that and "guess" an answer (If you can try to figure
    something better than guessing, go ahead and try).

    Your "logic" says that since it didn't reach and end state, that means
    it probably won't so your idea is to have H return 0 after it aborts its simulation. Thats fine, but when we look at the ACTUAL execution trace
    of the aborted simulation, and what that machine will do after that
    point, we find that it will ALSO do the same thing (not a surprise,
    since it is a copy of that H, it will do the same thing). Looking even
    farther we see that the continuation of the states defined by the input
    then return 0 to the D the outer H was simulating, and the the
    simulation reaches a final state and halts.

    Since this was based on the assumption that H returned non-halting, it
    turns out that H (and you) were wrong with the logic and assumption that
    the input would be non-halting, so it just got the wrong answer.

    We can do a similar analysis if for a third type of H that instead of
    returning non-halting, guesses Halting, and we find that it too will be
    wrong, as the D built on it will go into an infinite loop.

    We can see the issue is that we can never simulate the input far enough
    to see what it will do, because the outer machine is farther along than
    the machine it is simulating, so it can never find out what it will do
    until it first does it.

    Because the simulated machine starts behind, it can, after the outer
    machine aborts its simulation, get the same answer the outer machine was programmed for, and then it can choose to do the opposite.

    So, you need to decide what H is going to do before you can actually run
    the test. And having chosen that, it will turn out to be wrong.

    You can't say that H can't possibly abort its simulation before it has
    the answer, because it most certainly can, it just makes it give the
    wrong answer.

    It seems your problem is you don't understand that "Get the right
    answer" isn't an actual algorithm, and nothing actually promises that
    the can be an H that gets the answer correctly, so of course H can abort
    its simulation before it determines the correct answer, it just results
    in the possibility of it giving the wrong answer.

    All this just shows that you really don't understand how computations
    work, because you refused to learn about them, and made yourself totally ignorant of the subject, and then didn't let that lackof knowledge get
    in you way of making a fool of yourself.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 21:24:57 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 8:03 PM, olcott wrote:
    On 10/27/2023 6:16 PM, olcott wrote:
    On 10/27/2023 4:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2 >>>>>>>>>>>>>>>>>>>>>
    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider >>>>>>>>>>>>>>>>>>>>> that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to >>>>>>>>>>>>>>>>>>>>> report on the computation
    that contains itself thus breaking the rule that >>>>>>>>>>>>>>>>>>>>> all computations must
    be a pure functions of their inputs. >>>>>>>>>>>>>>>>>>>>>

    By the definition of computation that requires all >>>>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing Machine >>>>>>>>>>>>>>>>>>>> is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting that >>>>>>>>>>>>>>>>>>>> the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of >>>>>>>>>>>>>>>>>>>> Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs then >>>>>>>>>>>>>>>>>>> it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call >>>>>>>>>>>>>>>>>>> the exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation >>>>>>>>>>>>>>>>>>> that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED >>>>>>>>>>>>>>>>>> to decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually exclusive >>>>>>>>>>>>>>>>>> properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>>>>> inputs and the behavior of the computation that a decider >>>>>>>>>>>>>>>>>> is contained within is absolutely not a pure function its >>>>>>>>>>>>>>>>>> actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the
        input to the decider Halt?"

    Does D simulated by H reach it own final state? >>>>>>>>>>>>>>>>>

        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>>>> of states that it is actually presented with.

    This does include a call from its input to a copy of >>>>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description >>>>>>>>>>>>>>>> (b) The outermost H always has the most execution trace >>>>>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
    TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
    THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input >>>>>>>>>>>>>> and another definition of computation says that:
    (B) H is not allowed to look at the computation that >>>>>>>>>>>>>> contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>>>>> need to look at "itself" but at something that just happens >>>>>>>>>>>>> to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked >>>>>>>>>>>>> at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how >>>>>>>>>>>>> it continues*
    *to call embedded_H in recursive simulation until
    embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not> >>>>>>>>>>>> its input. This means that embedded_H is not allowed
    to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its >>>>>>>>>>> halt status decision on the behavior of the direct execution >>>>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second >>>>>>>>>>> part that <is> a necessary consequence of the first part. >>>>>>>>>>>
    I have no need to add ad hominem colored statement that
    this means you must be very bad at logic, I simply stick >>>>>>>>>>> with the objective facts and let the chips fall where they may. >>>>>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not >>>>>>>>>> the same behavior as the behavior of the direct execution
    of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call >>>>>>>>>> the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive >>>>>>>>>> simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input." >>>>>>>>>
    When a TM simply simulates the actual sequence of state
    transitions
    that it is presented with is called an incorrect simulation
    it is dead obvious that this is a bald-faced lie and cannot
    possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>>> 03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates >>>>>>>> D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own
    line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    "But the input CAN be the string
      that represents the program"

    That input program does specify the sequence of instructions
    that the above source-code shows. This sequence does show that D
    does call H in recursive simulation until H aborts this simulation.

    "And it shows that THAT H will abort its simulation and return 0 to D"

    It can't possibly do that because you insist that it is only allowed
    to report on the behavior after it does that and it doesn't do that
    after it has already done that.


    "H must report on the FULL behavior of the input."

    The full behavior of the actual input is that it
    never terminates normally and never terminates at
    all unless H sees that it never terminates normally
    and aborts it. It never halts.

    The full behavior of the computation that contains
    H cannot be reported on because computable functions
    are not allowed to report on the dynamic behavior
    of the same process that they are contained within.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 19:58:07 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 7:24 PM, olcott wrote:
    On 10/27/2023 8:03 PM, olcott wrote:
    On 10/27/2023 6:16 PM, olcott wrote:
    On 10/27/2023 4:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2 >>>>>>>>>>>>>>>>>>>>>>
    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider >>>>>>>>>>>>>>>>>>>>>> that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to >>>>>>>>>>>>>>>>>>>>>> report on the computation
    that contains itself thus breaking the rule that >>>>>>>>>>>>>>>>>>>>>> all computations must
    be a pure functions of their inputs. >>>>>>>>>>>>>>>>>>>>>>

    By the definition of computation that requires all >>>>>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing >>>>>>>>>>>>>>>>>>>>> Machine is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting that >>>>>>>>>>>>>>>>>>>>> the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of >>>>>>>>>>>>>>>>>>>>> Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs >>>>>>>>>>>>>>>>>>>> then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call >>>>>>>>>>>>>>>>>>>> the exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation >>>>>>>>>>>>>>>>>>>> that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED >>>>>>>>>>>>>>>>>>> to decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually >>>>>>>>>>>>>>>>>>> exclusive
    properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>>>>>> inputs and the behavior of the computation that a >>>>>>>>>>>>>>>>>>> decider
    is contained within is absolutely not a pure function >>>>>>>>>>>>>>>>>>> its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the >>>>>>>>>>>>>>>>>>     input to the decider Halt?"

    Does D simulated by H reach it own final state? >>>>>>>>>>>>>>>>>>

        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>>>>> of states that it is actually presented with. >>>>>>>>>>>>>>>>>
    This does include a call from its input to a copy of >>>>>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description >>>>>>>>>>>>>>>>> (b) The outermost H always has the most execution trace >>>>>>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE >>>>>>>>>>>>>>>> TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL >>>>>>>>>>>>>>>> THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input >>>>>>>>>>>>>>> and another definition of computation says that: >>>>>>>>>>>>>>> (B) H is not allowed to look at the computation that >>>>>>>>>>>>>>> contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>>>>>> need to look at "itself" but at something that just >>>>>>>>>>>>>> happens to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked >>>>>>>>>>>>>> at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how >>>>>>>>>>>>>> it continues*
    *to call embedded_H in recursive simulation until
    embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not> >>>>>>>>>>>>> its input. This means that embedded_H is not allowed >>>>>>>>>>>>> to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its >>>>>>>>>>>> halt status decision on the behavior of the direct execution >>>>>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second >>>>>>>>>>>> part that <is> a necessary consequence of the first part. >>>>>>>>>>>>
    I have no need to add ad hominem colored statement that >>>>>>>>>>>> this means you must be very bad at logic, I simply stick >>>>>>>>>>>> with the objective facts and let the chips fall where they may. >>>>>>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not >>>>>>>>>>> the same behavior as the behavior of the direct execution >>>>>>>>>>> of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call >>>>>>>>>>> the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive >>>>>>>>>>> simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input." >>>>>>>>>>
    When a TM simply simulates the actual sequence of state
    transitions
    that it is presented with is called an incorrect simulation >>>>>>>>>> it is dead obvious that this is a bald-faced lie and cannot >>>>>>>>>> possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>>>> 03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates >>>>>>>>> D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own >>>>>>>>> line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    "But the input CAN be the string
      that represents the program"

    That input program does specify the sequence of instructions
    that the above source-code shows. This sequence does show that D
    does call H in recursive simulation until H aborts this simulation.

    "And it shows that THAT H will abort its simulation and return 0 to D"

    It can't possibly do that because you insist that it is only allowed
    to report on the behavior after it does that and it doesn't do that
    after it has already done that.


    "H must report on the FULL behavior of the input."

    The full behavior of the actual input is that it
    never terminates normally and never terminates at
    all unless H sees that it never terminates normally
    and aborts it. It never halts.


    There is no "normally" about terminating.

    A program either terminates or it doesn't.

    An aborted simulation of an input doesn't "stop" the behavior of that
    input, as the behavior is DEFINED not by the potentially partial
    simulation of the decider, but by the actual behavior of the machine it represents, or the correct simulation of an actual UTM (which will never
    abort its simulation), and if H(D,D) returns 0, then we can show that
    the actual running, or UTM simulation of D(D) will have its H(D,D)
    return that same 0 and D(D) will Halt.


    H MUST have a defined answer from the beginning of what it answers to H(D,D)

    IF H(D,D) ever returns 0, it will ALWAYS return 0, and then the actual
    behavior of the input to H(D,D), which IS the behavior of D(D) is to
    Halt. PERIOD.

    IF H(D,D) ever returns 1, it will ALWAYS return 1, and then the actual
    behavior of the input to H(D,D), which is the behavior of D(D) is to
    never Halt, and H was wrong.

    If H(D,D) ever never returns, it will NEVER return an answer, and H is
    thus not a correct decider.

    So, your claim is a LIE.

    If you want to claim that the full behavior of the input to H(D,D) is non-halting, then the only way that can be is for H(D,D) to not return a
    0, as if it does, D will halt.

    So, your claim that the input of to H(D,D) is non-halting means that
    H(D,D) can not have ever returned a 0, so H is incorrect, as that means
    that you H is programmed to NEVER abort its simulation.


    The full behavior of the computation that contains
    H cannot be reported on because computable functions
    are not allowed to report on the dynamic behavior
    of the same process that they are contained within.


    No, H must report the result that its code WILL generate for this input.

    You seem to not understand that H WILL give what ever answer it is
    programmed to give, correct or incorrect.

    Note, H is NOT being aske to report on its own process, but on the
    process described to it, which just happens to be identical to it (which
    it can't know IS identical to it, because it doesn't know if D is
    calling it)

    Your logic is flawed, as you assume that some how magically H will must
    give the right answer, and if it can't we have a contradiction. There is nothing that says that H will give the right answer.

    You are just PROVING that you don't understand the meaning of the terms
    you are using, because you have made yourself INTENTIONALLY IGNORANT of
    the rules of computation, so you make effectively premeditated errors,
    which because of the fact that you refuse to learn after being taught,
    become blatant LIES.

    Yes, in one sense H "can't" report the behavior, but it "must" report
    that behavior, which means it MUST FAIL, as have you.

    The fact it must fail doesn't make the problem invalid, as computation
    theory accepts that not all problems have computable results, (and in
    fact, the big question is which problems ARE computable). It fully
    allows for uncomputable problems. A problem is "invalid" if there isn't
    a correct answer for the problem.

    Note, problems are normally specified based on trying to compute a
    "function", and if the "function" doesn't have a correct value for some
    input in the defined domain of the function, then the problem is invalid.

    We then ask if we can make a program that can compute that function for representations of the input to that function. And that can be Yes, or
    it can be No (and sometimes we need to say we don't know, and might find
    out later). For the Halting Problem the function is the Halting
    FUnction, and Halting(M,d) is True if M(d) will halt in a finite number
    of steps, and is False if it will never halt even with an unbounded
    number of steps.

    This function has a value for all actual Turing Machines M and inputs d,
    so is a VALID problem.

    It turns out that, because of this "pathological" input we can create,
    we can show that no machine can be created to compute it, so it is an uncomputable function. Which is fine.

    You just don't seem to understand what that means, because you brain
    power is just too weak.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Fri Oct 27 23:15:28 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/2023 9:24 PM, olcott wrote:
    On 10/27/2023 8:03 PM, olcott wrote:
    On 10/27/2023 6:16 PM, olcott wrote:
    On 10/27/2023 4:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote:
    On 10/26/2023 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2 >>>>>>>>>>>>>>>>>>>>>>
    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider >>>>>>>>>>>>>>>>>>>>>> that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to >>>>>>>>>>>>>>>>>>>>>> report on the computation
    that contains itself thus breaking the rule that >>>>>>>>>>>>>>>>>>>>>> all computations must
    be a pure functions of their inputs. >>>>>>>>>>>>>>>>>>>>>>

    By the definition of computation that requires all >>>>>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing >>>>>>>>>>>>>>>>>>>>> Machine is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting that >>>>>>>>>>>>>>>>>>>>> the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of >>>>>>>>>>>>>>>>>>>>> Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs >>>>>>>>>>>>>>>>>>>> then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call >>>>>>>>>>>>>>>>>>>> the exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally. >>>>>>>>>>>>>>>>>>>>
    It has no idea about the behavior of the computation >>>>>>>>>>>>>>>>>>>> that
    itself is embedded within.

    Maybe not, but it is the behavior that it is REQUIRED >>>>>>>>>>>>>>>>>>> to decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually >>>>>>>>>>>>>>>>>>> exclusive
    properties.

    Nothing is computable that is not a pure function of its >>>>>>>>>>>>>>>>>>> inputs and the behavior of the computation that a >>>>>>>>>>>>>>>>>>> decider
    is contained within is absolutely not a pure function >>>>>>>>>>>>>>>>>>> its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the >>>>>>>>>>>>>>>>>>     input to the decider Halt?"

    Does D simulated by H reach it own final state? >>>>>>>>>>>>>>>>>>

        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>>>>> of states that it is actually presented with. >>>>>>>>>>>>>>>>>
    This does include a call from its input to a copy of >>>>>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>>>>> copies unless this H right here stops them.

    If this H right here does not stop them then no H anywhere >>>>>>>>>>>>>>>>> will ever stop them because
    (a) They all have the same machine description >>>>>>>>>>>>>>>>> (b) The outermost H always has the most execution trace >>>>>>>>>>>>>>>>> information.


    H merely must simulate the actual sequence
    of states that it is actually presented with.

    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE >>>>>>>>>>>>>>>> TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL >>>>>>>>>>>>>>>> THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input >>>>>>>>>>>>>>> and another definition of computation says that: >>>>>>>>>>>>>>> (B) H is not allowed to look at the computation that >>>>>>>>>>>>>>> contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that H >>>>>>>>>>>>>> need to look at "itself" but at something that just >>>>>>>>>>>>>> happens to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked >>>>>>>>>>>>>> at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how >>>>>>>>>>>>>> it continues*
    *to call embedded_H in recursive simulation until
    embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must
    be a pure function of their inputs and itself <is not> >>>>>>>>>>>>> its input. This means that embedded_H is not allowed >>>>>>>>>>>>> to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its >>>>>>>>>>>> halt status decision on the behavior of the direct execution >>>>>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second >>>>>>>>>>>> part that <is> a necessary consequence of the first part. >>>>>>>>>>>>
    I have no need to add ad hominem colored statement that >>>>>>>>>>>> this means you must be very bad at logic, I simply stick >>>>>>>>>>>> with the objective facts and let the chips fall where they may. >>>>>>>>>>>
    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not >>>>>>>>>>> the same behavior as the behavior of the direct execution >>>>>>>>>>> of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call >>>>>>>>>>> the same function with the same input.

    As soon as embedded_H sees this once then it knows that
    it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of
    the copies wait for their copy to see this and the recursive >>>>>>>>>>> simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input." >>>>>>>>>>
    When a TM simply simulates the actual sequence of state
    transitions
    that it is presented with is called an incorrect simulation >>>>>>>>>> it is dead obvious that this is a bald-faced lie and cannot >>>>>>>>>> possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>>>> 03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that simulates >>>>>>>>> D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own >>>>>>>>> line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with.


        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    "But the input CAN be the string
      that represents the program"

    That input program does specify the sequence of instructions
    that the above source-code shows. This sequence does show that D
    does call H in recursive simulation until H aborts this simulation.

    "And it shows that THAT H will abort its simulation and return 0 to D"

    It can't possibly do that because you insist that it is only allowed
    to report on the behavior after it does that and it doesn't do that
    after it has already done that.


    "H must report on the FULL behavior of the input."

    The full behavior of the actual input is that it
    never terminates normally and never terminates at
    all unless H sees that it never terminates normally
    and aborts it. It never halts.

    The full behavior of the computation that contains
    H cannot be reported on because computable functions
    are not allowed to report on the dynamic behavior
    of the same process that they are contained within.


    "There is no "normally" about terminating."
    The Turing Machine equivalent of the software engineering term
    {terminate normally} is {reach final state and halt}.

    When we are dealing with actual machines we must
    account for stack overflow abnormal termination.




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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 21:49:32 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 9:15 PM, olcott wrote:
    On 10/27/2023 9:24 PM, olcott wrote:
    On 10/27/2023 8:03 PM, olcott wrote:
    On 10/27/2023 6:16 PM, olcott wrote:
    On 10/27/2023 4:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/26/2023 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞ >>>>>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2 >>>>>>>>>>>>>>>>>>>>>>>
    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider >>>>>>>>>>>>>>>>>>>>>>> that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to >>>>>>>>>>>>>>>>>>>>>>> report on the computation
    that contains itself thus breaking the rule that >>>>>>>>>>>>>>>>>>>>>>> all computations must
    be a pure functions of their inputs. >>>>>>>>>>>>>>>>>>>>>>>

    By the definition of computation that requires all >>>>>>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing >>>>>>>>>>>>>>>>>>>>>> Machine is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting >>>>>>>>>>>>>>>>>>>>>> that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of >>>>>>>>>>>>>>>>>>>>>> Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs >>>>>>>>>>>>>>>>>>>>> then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call >>>>>>>>>>>>>>>>>>>>> the exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the >>>>>>>>>>>>>>>>>>>>> computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is >>>>>>>>>>>>>>>>>>>> REQUIRED to decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually >>>>>>>>>>>>>>>>>>>> exclusive
    properties.

    Nothing is computable that is not a pure function of >>>>>>>>>>>>>>>>>>>> its
    inputs and the behavior of the computation that a >>>>>>>>>>>>>>>>>>>> decider
    is contained within is absolutely not a pure >>>>>>>>>>>>>>>>>>>> function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the >>>>>>>>>>>>>>>>>>>     input to the decider Halt?"

    Does D simulated by H reach it own final state? >>>>>>>>>>>>>>>>>>>

        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>>>>>> of states that it is actually presented with. >>>>>>>>>>>>>>>>>>
    This does include a call from its input to a copy of >>>>>>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>>>>>> copies unless this H right here stops them. >>>>>>>>>>>>>>>>>>
    If this H right here does not stop them then no H >>>>>>>>>>>>>>>>>> anywhere
    will ever stop them because
    (a) They all have the same machine description >>>>>>>>>>>>>>>>>> (b) The outermost H always has the most execution >>>>>>>>>>>>>>>>>> trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with. >>>>>>>>>>>>>>>>>
    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE >>>>>>>>>>>>>>>>> TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL >>>>>>>>>>>>>>>>> THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input >>>>>>>>>>>>>>>> and another definition of computation says that: >>>>>>>>>>>>>>>> (B) H is not allowed to look at the computation that >>>>>>>>>>>>>>>> contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that >>>>>>>>>>>>>>> H need to look at "itself" but at something that just >>>>>>>>>>>>>>> happens to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be >>>>>>>>>>>>>>> looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how >>>>>>>>>>>>>>> it continues*
    *to call embedded_H in recursive simulation until >>>>>>>>>>>>>>> embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must >>>>>>>>>>>>>> be a pure function of their inputs and itself <is not> >>>>>>>>>>>>>> its input. This means that embedded_H is not allowed >>>>>>>>>>>>>> to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its >>>>>>>>>>>>> halt status decision on the behavior of the direct execution >>>>>>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second >>>>>>>>>>>>> part that <is> a necessary consequence of the first part. >>>>>>>>>>>>>
    I have no need to add ad hominem colored statement that >>>>>>>>>>>>> this means you must be very bad at logic, I simply stick >>>>>>>>>>>>> with the objective facts and let the chips fall where they >>>>>>>>>>>>> may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not >>>>>>>>>>>> the same behavior as the behavior of the direct execution >>>>>>>>>>>> of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call >>>>>>>>>>>> the same function with the same input.

    As soon as embedded_H sees this once then it knows that >>>>>>>>>>>> it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of >>>>>>>>>>>> the copies wait for their copy to see this and the recursive >>>>>>>>>>>> simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input." >>>>>>>>>>>
    When a TM simply simulates the actual sequence of state
    transitions
    that it is presented with is called an incorrect simulation >>>>>>>>>>> it is dead obvious that this is a bald-faced lie and cannot >>>>>>>>>>> possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>>>>> 03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that
    simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own >>>>>>>>>> line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with. >>>>>>>>>

        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    "But the input CAN be the string
      that represents the program"

    That input program does specify the sequence of instructions
    that the above source-code shows. This sequence does show that D
    does call H in recursive simulation until H aborts this simulation.

    "And it shows that THAT H will abort its simulation and return 0 to D"

    It can't possibly do that because you insist that it is only allowed
    to report on the behavior after it does that and it doesn't do that
    after it has already done that.


    "H must report on the FULL behavior of the input."

    The full behavior of the actual input is that it
    never terminates normally and never terminates at
    all unless H sees that it never terminates normally
    and aborts it. It never halts.

    The full behavior of the computation that contains
    H cannot be reported on because computable functions
    are not allowed to report on the dynamic behavior
    of the same process that they are contained within.


    "There is no "normally" about terminating."
    The Turing Machine equivalent of the software engineering term
    {terminate normally} is {reach final state and halt}.

    When we are dealing with actual machines we must
    account for stack overflow abnormal termination.



    But "Computation Theory" isn't talking about our "modern" computers, but
    a theoretical model of computation. Remember, when it stated, a
    "Computer" was a person with a pad of paper, a pencil, and maybe some
    other aids.

    Turing Machine don't have a "stack overflow" abnormal termination.

    So, you are just admitting that you totally don't understand what you
    are talking about.

    Yes, we apply the theoretical results to the practical machines, and
    realize that there is an approximation, but things like the Halting
    Theorem are about these Theoretical Idealized machines.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Oct 27 21:53:47 2023
    XPost: comp.theory, sci.logic, sci.math

    On 10/27/23 9:15 PM, olcott wrote:
    On 10/27/2023 9:24 PM, olcott wrote:
    On 10/27/2023 8:03 PM, olcott wrote:
    On 10/27/2023 6:16 PM, olcott wrote:
    On 10/27/2023 4:08 PM, olcott wrote:
    On 10/27/2023 3:31 PM, olcott wrote:
    On 10/27/2023 2:24 PM, olcott wrote:
    On 10/27/2023 1:41 PM, olcott wrote:
    On 10/27/2023 12:59 PM, olcott wrote:
    On 10/27/2023 12:20 PM, olcott wrote:
    On 10/27/2023 12:16 PM, olcott wrote:
    On 10/27/2023 10:57 AM, olcott wrote:
    On 10/27/2023 10:05 AM, olcott wrote:
    On 10/27/2023 9:26 AM, olcott wrote:
    On 10/26/2023 11:04 PM, olcott wrote:
    On 10/26/2023 9:48 PM, olcott wrote:
    On 10/26/2023 8:28 PM, olcott wrote:
    On 10/26/2023 8:09 PM, olcott wrote:
    On 10/26/2023 7:37 PM, olcott wrote:
    On 10/26/2023 4:35 PM, olcott wrote:
    On 10/26/2023 3:12 PM, olcott wrote:
    On 10/26/2023 1:59 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/26/2023 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>>>>>
    This Turing Machine description at the top of page 3 >>>>>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞ >>>>>>>>>>>>>>>>>>>>>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2 >>>>>>>>>>>>>>>>>>>>>>>
    Is simplified and clarified to this: when Ĥ is >>>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩

    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>>>>>>>
    embedded_H is expressly not allowed to consider >>>>>>>>>>>>>>>>>>>>>>> that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
    and halts because this requires embedded_H to >>>>>>>>>>>>>>>>>>>>>>> report on the computation
    that contains itself thus breaking the rule that >>>>>>>>>>>>>>>>>>>>>>> all computations must
    be a pure functions of their inputs. >>>>>>>>>>>>>>>>>>>>>>>

    By the definition of computation that requires all >>>>>>>>>>>>>>>>>>>>>> computations to
    be a pure function of their inputs no Turing >>>>>>>>>>>>>>>>>>>>>> Machine is allowed to
    report on the computation that itself is contained >>>>>>>>>>>>>>>>>>>>>> within.

    This utterly forbids embedded_H from reporting >>>>>>>>>>>>>>>>>>>>>> that the directly
    executed Ĥ ⟨Ĥ⟩ transitions to its final state of >>>>>>>>>>>>>>>>>>>>>> Ĥ.qn and halts.

    That is <not> the behavior that embedded_H sees. >>>>>>>>>>>>>>>>>>>>>
    When embedded_H is a pure function of its inputs >>>>>>>>>>>>>>>>>>>>> then it sees
    that ⟨Ĥ⟩ simulated by embedded_H continues to call >>>>>>>>>>>>>>>>>>>>> the exact
    same machine with the exact same input, recursively >>>>>>>>>>>>>>>>>>>>> such that
    the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

    It has no idea about the behavior of the >>>>>>>>>>>>>>>>>>>>> computation that
    itself is embedded within.

    Maybe not, but it is the behavior that it is >>>>>>>>>>>>>>>>>>>> REQUIRED to decide on to be correct.

    That is either a widely held misconception or an the >>>>>>>>>>>>>>>>>>>> incoherent requirement of simultaneous mutually >>>>>>>>>>>>>>>>>>>> exclusive
    properties.

    Nothing is computable that is not a pure function of >>>>>>>>>>>>>>>>>>>> its
    inputs and the behavior of the computation that a >>>>>>>>>>>>>>>>>>>> decider
    is contained within is absolutely not a pure >>>>>>>>>>>>>>>>>>>> function its
    actual inputs.

        So, what else could the ACTUAL
        Halting question of:
        "Does the machine represented by the >>>>>>>>>>>>>>>>>>>     input to the decider Halt?"

    Does D simulated by H reach it own final state? >>>>>>>>>>>>>>>>>>>

        Which is only correct *IF* H meets
        the definition of a UTM,

    Not at all. H merely must simulate the actual sequence >>>>>>>>>>>>>>>>>> of states that it is actually presented with. >>>>>>>>>>>>>>>>>>
    This does include a call from its input to a copy of >>>>>>>>>>>>>>>>>> itself that will never stop copying and calling other >>>>>>>>>>>>>>>>>> copies unless this H right here stops them. >>>>>>>>>>>>>>>>>>
    If this H right here does not stop them then no H >>>>>>>>>>>>>>>>>> anywhere
    will ever stop them because
    (a) They all have the same machine description >>>>>>>>>>>>>>>>>> (b) The outermost H always has the most execution >>>>>>>>>>>>>>>>>> trace information.


    H merely must simulate the actual sequence
    of states that it is actually presented with. >>>>>>>>>>>>>>>>>
    THIS DOES INCLUDE THAT THESE STATES DO CONTINUE >>>>>>>>>>>>>>>>> TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL >>>>>>>>>>>>>>>>> THIS H STOPS THEM

    When one definition says that:
    (A) H must look at the direct execution of its input >>>>>>>>>>>>>>>> and another definition of computation says that: >>>>>>>>>>>>>>>> (B) H is not allowed to look at the computation that >>>>>>>>>>>>>>>> contains itself

    THEY CAN'T BOTH BE RIGHT


    But how does (B) apply, since the input doesn't say that >>>>>>>>>>>>>>> H need to look at "itself" but at something that just >>>>>>>>>>>>>>> happens to be copy of itself.

    When Ĥ is applied to ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>
    Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be >>>>>>>>>>>>>>> looked at and
    this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how >>>>>>>>>>>>>>> it continues*
    *to call embedded_H in recursive simulation until >>>>>>>>>>>>>>> embedded_H stops it*


    No decider is allowed yo examine the computation
    that contains itself because all computations must >>>>>>>>>>>>>> be a pure function of their inputs and itself <is not> >>>>>>>>>>>>>> its input. This means that embedded_H is not allowed >>>>>>>>>>>>>> to look at the direct execution of Ĥ ⟨Ĥ⟩.

    Since we know that embedded_H is not allowed to base its >>>>>>>>>>>>> halt status decision on the behavior of the direct execution >>>>>>>>>>>>> of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision >>>>>>>>>>>>> of this basis is known to be incorrect.

    You agree with the first part and disagree with the second >>>>>>>>>>>>> part that <is> a necessary consequence of the first part. >>>>>>>>>>>>>
    I have no need to add ad hominem colored statement that >>>>>>>>>>>>> this means you must be very bad at logic, I simply stick >>>>>>>>>>>>> with the objective facts and let the chips fall where they >>>>>>>>>>>>> may.

    It is very easy to verify that the behavior specified
    to embedded_H by the machine description of ⟨Ĥ⟩ is not >>>>>>>>>>>> the same behavior as the behavior of the direct execution >>>>>>>>>>>> of Ĥ ⟨Ĥ⟩.

    embedded_H only sees ⟨Ĥ⟩ continuing to recursively call >>>>>>>>>>>> the same function with the same input.

    As soon as embedded_H sees this once then it knows that >>>>>>>>>>>> it must abort the simulation of its input. This <is>
    before any copy of embedded_H sees this once.

    If embedded_H waits for a copy to see this then all of >>>>>>>>>>>> the copies wait for their copy to see this and the recursive >>>>>>>>>>>> simulation never stops.

    "Because it doesn't know how to CORRECTLY simulate its input." >>>>>>>>>>>
    When a TM simply simulates the actual sequence of state
    transitions
    that it is presented with is called an incorrect simulation >>>>>>>>>>> it is dead obvious that this is a bald-faced lie and cannot >>>>>>>>>>> possibly be reasonably construed as any honest mistake.


    // The following is written in C
    //
    01 typedef int (*ptr)(); // pointer to int function
    02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>>>>> 03
    04 int D(ptr x)
    05 {
    06   int Halt_Status = H(x, x);
    07   if (Halt_Status)
    08     HERE: goto HERE;
    09   return Halt_Status;
    10 }
    11
    12 void main()
    13 {
    14   H(D,D);
    15 }

    *Execution Trace*
    Line 14: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 06: simulated D(D) invokes simulated H(D,D) that
    simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own >>>>>>>>>> line 06
    to its own final state at line 09.


    "The actual sequence of state transitions that happens when
    we actually run the program described by the input"

    Is dead obviously not the sequence that H is presented with. >>>>>>>>>

        Then H isn't a Halt Decier. PERIOD.

        Because the behavior described by
        the input to a Halt Decider is the
        sequence of state transitions that
        happes when you actually run the program
        described by the input.

    You already agreed that it is not allowed to consider
    the sequence of state transitions that happens when you
    actually run the program for embedded_H.

    The same thing applies with the direct execution of
    D(D) where H is required to report on the behavior
    of the computation that itself is contained within.

    I present H/D to make it totally clear that the
    sequence of state transitions that happens when you
    actually run the program IS NOT THE SEQUENCE THAT
    H IS PRESENTED WITH.

    int sum(int x, int y) {  return x + y; }
    sum(3,4) is not allowed to report on the sum of 5 + 6.


        No, I said you can't ask H/embedded_H
        about "the program that is calling/using it".

    Likewise we cannot ask H about the direct execution
    of D(D) (the program calling/using it).


    We can never ask H about the behavior of the direct execution
    of D(D) because doing this not allowed by any computation
    that must be a pure function of its inputs and the computation
    that contains itself is definitely not an input.

    We can ask H about the execution trace of the sequence of
    instructions that are specified as an input to H. When we
    do this we are not allowed to simply ignore any of the
    instructions in this specified sequence. This means that
    we are required to consider that D does call H in recursive
    simulation.


    "Except that it CAN be the input too."

    H cannot possibly have its own dynamically executing
    process as an input to itself because inputs must be
    static finite strings.


    "But the input CAN be the string
      that represents the program"

    That input program does specify the sequence of instructions
    that the above source-code shows. This sequence does show that D
    does call H in recursive simulation until H aborts this simulation.

    "And it shows that THAT H will abort its simulation and return 0 to D"

    It can't possibly do that because you insist that it is only allowed
    to report on the behavior after it does that and it doesn't do that
    after it has already done that.


    "H must report on the FULL behavior of the input."

    The full behavior of the actual input is that it
    never terminates normally and never terminates at
    all unless H sees that it never terminates normally
    and aborts it. It never halts.

    The full behavior of the computation that contains
    H cannot be reported on because computable functions
    are not allowed to report on the dynamic behavior
    of the same process that they are contained within.


    "There is no "normally" about terminating."
    The Turing Machine equivalent of the software engineering term
    {terminate normally} is {reach final state and halt}.

    When we are dealing with actual machines we must
    account for stack overflow abnormal termination.


    Also, a computation that ends via a stack overflow just means that our
    physical approximation to the ideal machine wasn't good enough, and we
    need a better one, in order to determine if the computation actually
    halts or not.

    So, "abnormal termination" means halting is still undecided, not that it
    is non-halting. We may be able, in SOME cases, to analyse the final
    crash dump to determine if we can prove that we were in a provably
    non-halting loop, but we can't take that for granted.

    So, H aborting its simulation just means that it doesn't yet know if its
    input was Halting or not.

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