• Re: Concise refutation of halting problem proofs V63 [ Linz Proof ](dec

    From olcott@21:1/5 to Ben Bacarisse on Fri Feb 18 22:16:03 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final state of M

    RHS is a paraphrase of Ben Bacarisse encoding of my halt status
    criterion measure.

    I never encoded your "halt status criterion measure" so you can not be
    paraphrasing such a thing here. I re-wrote Linz's condition in terms of >>> a UTM.

    That is exactly the same thing that I am referring to.

    Are you reneging on the silly claim that false (or reject) is the correct answer for at least one halting computation? A direct answer would be appreciated.


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

    The copy of H at Ĥ.qx will be referred to as embedded_H.

    Because simulating halt deciders are deciders they are only accountable
    for computing the mapping from their finite string pair** inputs to an
    accept or reject state entirely on the basis of the whether or not their
    pure simulation of this input pair would ever reach its own final state.

    ** (Turing machine description / finite string)

    Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
    final state of ⟨Ĥ⟩.qn in any finite number of simulated steps embedded_H is necessarily correct to transition to Ĥ.qn.

    embedded_H is not accountable for reporting on the behavior of the
    computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not an actual input and deciders are only accountable for computing the mapping
    from their inputs to an accept / reject state.

    https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3


    --
    Copyright 2021 Pete 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 Richard Damon on Sat Feb 19 09:02:13 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 8:46 AM, Richard Damon wrote:
    On 2/19/22 9:24 AM, olcott wrote:
    On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final >>>>>>>> state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the
    final state of M

    RHS is a paraphrase of Ben Bacarisse encoding of my halt status >>>>>>>> criterion measure.

    I never encoded your "halt status criterion measure" so you can
    not be
    paraphrasing such a thing here.  I re-wrote Linz's condition in >>>>>>> terms of
    a UTM.

    That is exactly the same thing that I am referring to.

    Are you reneging on the silly claim that false (or reject) is the
    correct
    answer for at least one halting computation?  A direct answer would be >>>>> appreciated.

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

    No answer to my direct question (I didn't expect one -- the answer is
    embarrassing to you).

    The copy of H at Ĥ.qx will be referred to as embedded_H.

    No answer to my question.

    Because simulating halt deciders are deciders they are only
    accountable for computing the mapping from their finite string pair**
    inputs to an accept or reject state entirely on the basis of the
    whether or not their pure simulation of this input pair would ever
    reach its own final state.

    Still no answer.

    ** (Turing machine description / finite string)

    Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
    final state of ⟨Ĥ⟩.qn in any finite number of simulated steps
    embedded_H is necessarily correct to transition to Ĥ.qn.

    Still no answer.

    embedded_H is not accountable for reporting on the behavior of the
    computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not >>>> an actual input and deciders are only accountable for computing the
    mapping from their inputs to an accept / reject state.

    Still no answer.

    I provided the answer via all of the reasoning that derives the answer.

    It is correct for Ĥ ⟨Ĥ⟩ to transition to Ĥ.qn even though Ĥ ⟨Ĥ⟩ halts
    because all simulating halt deciders are deciders thus embedded_H is
    only accountable for computing the mapping of its actual inputs: ⟨Ĥ⟩
    ⟨Ĥ⟩ to an accept or reject state on the basis of whether or not its
    pure simulation of this input ever reaches its final state of ⟨Ĥ⟩.qn. >>
    embedded_H is not accountable for the behavior of the computation that
    contains it: Ĥ ⟨Ĥ⟩ because it is not an actual input to embedded_H.


    In other words, it is correct to give the wrong answer because H isn't actually a Halt Decider, but only plays one on TV.
    Because simulating halt deciders are deciders they are only accountable
    for the actual behavior of their actual input, like a guard that is in
    charge of guarding the front door.

    Any behavior that is not the behavior of their actual input is like
    someone coming in the back door, the simulating halt decider is not
    accountable for this behavior.

    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sat Feb 19 08:24:58 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final state of M

    RHS is a paraphrase of Ben Bacarisse encoding of my halt status
    criterion measure.

    I never encoded your "halt status criterion measure" so you can not be >>>>> paraphrasing such a thing here. I re-wrote Linz's condition in terms of >>>>> a UTM.

    That is exactly the same thing that I am referring to.

    Are you reneging on the silly claim that false (or reject) is the correct >>> answer for at least one halting computation? A direct answer would be
    appreciated.

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

    No answer to my direct question (I didn't expect one -- the answer is embarrassing to you).

    The copy of H at Ĥ.qx will be referred to as embedded_H.

    No answer to my question.

    Because simulating halt deciders are deciders they are only
    accountable for computing the mapping from their finite string pair**
    inputs to an accept or reject state entirely on the basis of the
    whether or not their pure simulation of this input pair would ever
    reach its own final state.

    Still no answer.

    ** (Turing machine description / finite string)

    Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
    final state of ⟨Ĥ⟩.qn in any finite number of simulated steps
    embedded_H is necessarily correct to transition to Ĥ.qn.

    Still no answer.

    embedded_H is not accountable for reporting on the behavior of the
    computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not >> an actual input and deciders are only accountable for computing the
    mapping from their inputs to an accept / reject state.

    Still no answer.

    I provided the answer via all of the reasoning that derives the answer.

    It is correct for Ĥ ⟨Ĥ⟩ to transition to Ĥ.qn even though Ĥ ⟨Ĥ⟩ halts
    because all simulating halt deciders are deciders thus embedded_H is
    only accountable for computing the mapping of its actual inputs: ⟨Ĥ⟩ ⟨Ĥ⟩
    to an accept or reject state on the basis of whether or not its pure
    simulation of this input ever reaches its final state of ⟨Ĥ⟩.qn.

    embedded_H is not accountable for the behavior of the computation that
    contains it: Ĥ ⟨Ĥ⟩ because it is not an actual input to embedded_H.

    --
    Copyright 2021 Pete 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 Richard Damon on Sat Feb 19 08:39:35 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 8:09 AM, Richard Damon wrote:
    On 2/18/22 11:16 PM, olcott wrote:
    On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state
    of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the
    final state of M

    RHS is a paraphrase of Ben Bacarisse encoding of my halt status
    criterion measure.

    I never encoded your "halt status criterion measure" so you can not be >>>>> paraphrasing such a thing here.  I re-wrote Linz's condition in
    terms of
    a UTM.

    That is exactly the same thing that I am referring to.

    Are you reneging on the silly claim that false (or reject) is the
    correct
    answer for at least one halting computation?  A direct answer would be
    appreciated.


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

    The copy of H at Ĥ.qx will be referred to as embedded_H.

    Because simulating halt deciders are deciders they are only
    accountable for computing the mapping from their finite string pair**
    inputs to an accept or reject state entirely on the basis of the
    whether or not their pure simulation of this input pair would ever
    reach its own final state.

    Except that embedded_H does NOT do a pure simulation of its input

    _Infinite_Loop()
    [00000946](01) 55 push ebp
    [00000947](02) 8bec mov ebp,esp
    [00000949](02) ebfe jmp 00000949
    [0000094b](01) 5d pop ebp
    [0000094c](01) c3 ret
    Size in bytes:(0007) [0000094c]

    embedded_H need not do a pure simulation of its input it only needs to determine that if it did do a pure simulation of the input it would
    never reach the final state of this simulated input.

    As soon as a simulating halt decider correctly recognizes an infinite
    behavior pattern in its simulation of an input it correctly rejects this
    input.

    https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3


    --
    Copyright 2021 Pete 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 Richard Damon on Sat Feb 19 09:05:25 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 8:50 AM, Richard Damon wrote:
    On 2/19/22 9:39 AM, olcott wrote:
    On 2/19/2022 8:09 AM, Richard Damon wrote:
    On 2/18/22 11:16 PM, olcott wrote:
    On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final >>>>>>>> state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the
    final state of M

    RHS is a paraphrase of Ben Bacarisse encoding of my halt status >>>>>>>> criterion measure.

    I never encoded your "halt status criterion measure" so you can
    not be
    paraphrasing such a thing here.  I re-wrote Linz's condition in >>>>>>> terms of
    a UTM.

    That is exactly the same thing that I am referring to.

    Are you reneging on the silly claim that false (or reject) is the
    correct
    answer for at least one halting computation?  A direct answer would be >>>>> appreciated.


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

    The copy of H at Ĥ.qx will be referred to as embedded_H.

    Because simulating halt deciders are deciders they are only
    accountable for computing the mapping from their finite string
    pair** inputs to an accept or reject state entirely on the basis of
    the whether or not their pure simulation of this input pair would
    ever reach its own final state.

    Except that embedded_H does NOT do a pure simulation of its input

    _Infinite_Loop()
    [00000946](01)  55              push ebp
    [00000947](02)  8bec            mov ebp,esp
    [00000949](02)  ebfe            jmp 00000949
    [0000094b](01)  5d              pop ebp
    [0000094c](01)  c3              ret
    Size in bytes:(0007) [0000094c]

    embedded_H need not do a pure simulation of its input it only needs to
    determine that if it did do a pure simulation of the input it would
    never reach the final state of this simulated input.

    As soon as a simulating halt decider correctly recognizes an infinite
    behavior pattern in its simulation of an input it correctly rejects
    this input.

    https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3



    RED HERRING.

    You can't use the 'simulation' of the input by H to show that it is non-halting if H aborts its simulation and is thus not a UTM.

    In other words it is impossible to tell that _Infinite_Loop() will never
    reach its machine address of [0000094c] until after simulating
    _Infinite_Loop() forever?


    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sat Feb 19 11:49:26 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 11:36 AM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final state of M

    RHS is a paraphrase of Ben Bacarisse encoding of my halt status >>>>>>>> criterion measure.

    I never encoded your "halt status criterion measure" so you can not be >>>>>>> paraphrasing such a thing here. I re-wrote Linz's condition in terms of
    a UTM.

    That is exactly the same thing that I am referring to.

    Are you reneging on the silly claim that false (or reject) is the correct >>>>> answer for at least one halting computation? A direct answer would be >>>>> appreciated.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    No answer to my direct question (I didn't expect one -- the answer is
    embarrassing to you).

    The copy of H at Ĥ.qx will be referred to as embedded_H.
    No answer to my question.

    Because simulating halt deciders are deciders they are only
    accountable for computing the mapping from their finite string pair**
    inputs to an accept or reject state entirely on the basis of the
    whether or not their pure simulation of this input pair would ever
    reach its own final state.
    Still no answer.

    ** (Turing machine description / finite string)

    Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
    final state of ⟨Ĥ⟩.qn in any finite number of simulated steps
    embedded_H is necessarily correct to transition to Ĥ.qn.
    Still no answer.

    embedded_H is not accountable for reporting on the behavior of the
    computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not >>>> an actual input and deciders are only accountable for computing the
    mapping from their inputs to an accept / reject state.
    Still no answer.

    I provided the answer via all of the reasoning that derives the
    answer.

    No you didn't. You waffled. The answer is a simple yes or no since you
    have either accepted that you were wrong before or you have not.


    A simple yes or no is far too easy to reject out-of-hand without review.
    When I provide the answer as all of the reasoning that supports the yes
    or no without providing the actual yes or no this answer cannot be
    rejected out-of-hand without review.

    But we know the answer because you have invented a whole swathe of
    made-up terms in order to try to hide what you were once happy to be
    clear about: that you consider the wrong answer to be the right one.

    Of course, being clear about that meant you were in danger of being
    ignored (no one cares about the problem that is not the halting
    problem), so you stared a long campaign of waffling. You've used ever
    more obtuse phrasing in an attempt to make it /less/ clear, but I
    remember when you were not being so coy about it.

    (A) You are not talking about the halting problem because you accept
    false as the correct answer for at least one halting computation.

    (B) You are not talking about Turing machines because you assert that
    two identical collections of states and associated transition
    clauses can transition to different states when given the same tape
    input.

    Apart from A and B, you are bang on track!


    It is clear that you made sure to ignore every single word that I said
    and/or are simply totally ignorant of the fact that all deciders compute
    the mapping from their inputs to an accept or reject state.

    --
    Copyright 2021 Pete 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 Richard Damon on Sat Feb 19 12:07:37 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 11:45 AM, Richard Damon wrote:

    On 2/19/22 12:36 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    I provided the answer via all of the reasoning that derives the
    answer.

    No you didn't.  You waffled.  The answer is a simple yes or no since you >> have either accepted that you were wrong before or you have not.

    But we know the answer because you have invented a whole swathe of
    made-up terms in order to try to hide what you were once happy to be
    clear about: that you consider the wrong answer to be the right one.

    Of course, being clear about that meant you were in danger of being
    ignored (no one cares about the problem that is not the halting
    problem), so you stared a long campaign of waffling.  You've used ever
    more obtuse phrasing in an attempt to make it /less/ clear, but I
    remember when you were not being so coy about it.

    (A) You are not talking about the halting problem because you accept
         false as the correct answer for at least one halting computation. >>
    (B) You are not talking about Turing machines because you assert that
         two identical collections of states and associated transition
         clauses can transition to different states when given the same tape >>      input.

    Apart from A and B, you are bang on track!


    Actually, he's been explicit that he isn't working on the Halting
    problem by his statement that H applied <H^> <H^> isn't required to
    answer about the behavior of H^ applied to <H^> which a Halt Decider is.

    He isn't just giving a wrong answer, he claims his answer isn't based on
    the mapping that a Halt Decider is supposed to be computing.


    Try and find a consensus of computer scientists that disagree that:

    (a) A decider computes the mapping from its inputs to a final accept or
    reject state.

    (b) A halt decider is a decider.

    --
    Copyright 2021 Pete 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 Richard Damon on Sat Feb 19 13:08:58 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 12:55 PM, Richard Damon wrote:
    On 2/19/22 1:07 PM, olcott wrote:
    On 2/19/2022 11:45 AM, Richard Damon wrote:

    On 2/19/22 12:36 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    I provided the answer via all of the reasoning that derives the
    answer.

    No you didn't.  You waffled.  The answer is a simple yes or no since >>>> you
    have either accepted that you were wrong before or you have not.

    But we know the answer because you have invented a whole swathe of
    made-up terms in order to try to hide what you were once happy to be
    clear about: that you consider the wrong answer to be the right one.

    Of course, being clear about that meant you were in danger of being
    ignored (no one cares about the problem that is not the halting
    problem), so you stared a long campaign of waffling.  You've used ever >>>> more obtuse phrasing in an attempt to make it /less/ clear, but I
    remember when you were not being so coy about it.

    (A) You are not talking about the halting problem because you accept
         false as the correct answer for at least one halting computation. >>>>
    (B) You are not talking about Turing machines because you assert that
         two identical collections of states and associated transition >>>>      clauses can transition to different states when given the same >>>> tape
         input.

    Apart from A and B, you are bang on track!


    Actually, he's been explicit that he isn't working on the Halting
    problem by his statement that H applied <H^> <H^> isn't required to
    answer about the behavior of H^ applied to <H^> which a Halt Decider is. >>>
    He isn't just giving a wrong answer, he claims his answer isn't based
    on the mapping that a Halt Decider is supposed to be computing.


    Try and find a consensus of computer scientists that disagree that:

    (a) A decider computes the mapping from its inputs to a final accept
    or reject state.

    (b) A halt decider is a decider.


    No complaints about that, the issue is that a Halt Decider needs to
    compute the Halting function which is the mapping of the behavior of the machine that its input represents.
    The way that you use the term "Represents" diverges from "specifies".

    When a policeman interviews Sam to see if Bill was at Sam's house last
    night between 8:00 PM and 10:00 PM if Sam says yes on the basis that
    Bill's lawyer (that represents Bill) was at his house, Sam made a false
    police report and can go to jail.

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

    The actual behavior that an input pair specifies is determined by the simulation of this input pair at the Ĥ.qx point in the execution trace.



    --
    Copyright 2021 Pete 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 Sat Feb 19 12:52:48 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 12:07 PM, olcott wrote:
    On 2/19/2022 11:45 AM, Richard Damon wrote:

    On 2/19/22 12:36 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    I provided the answer via all of the reasoning that derives the
    answer.

    No you didn't.  You waffled.  The answer is a simple yes or no since you >>> have either accepted that you were wrong before or you have not.

    But we know the answer because you have invented a whole swathe of
    made-up terms in order to try to hide what you were once happy to be
    clear about: that you consider the wrong answer to be the right one.

    Of course, being clear about that meant you were in danger of being
    ignored (no one cares about the problem that is not the halting
    problem), so you stared a long campaign of waffling.  You've used ever
    more obtuse phrasing in an attempt to make it /less/ clear, but I
    remember when you were not being so coy about it.

    (A) You are not talking about the halting problem because you accept
         false as the correct answer for at least one halting computation. >>>
    (B) You are not talking about Turing machines because you assert that
         two identical collections of states and associated transition
         clauses can transition to different states when given the same tape
         input.

    Apart from A and B, you are bang on track!


    Actually, he's been explicit that he isn't working on the Halting
    problem by his statement that H applied <H^> <H^> isn't required to
    answer about the behavior of H^ applied to <H^> which a Halt Decider is.

    He isn't just giving a wrong answer, he claims his answer isn't based
    on the mapping that a Halt Decider is supposed to be computing.


    Try and find a consensus of computer scientists that disagree that:

    (a) A decider computes the mapping from its inputs to a final accept or reject state.

    (b) A halt decider is a decider.


    I just found a PhD computer scientist that agreed.

    --
    Copyright 2021 Pete 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 Richard Damon on Sat Feb 19 13:58:36 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 1:48 PM, Richard Damon wrote:
    On 2/19/22 2:08 PM, olcott wrote:
    On 2/19/2022 12:55 PM, Richard Damon wrote:
    On 2/19/22 1:07 PM, olcott wrote:
    On 2/19/2022 11:45 AM, Richard Damon wrote:

    On 2/19/22 12:36 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    I provided the answer via all of the reasoning that derives the
    answer.

    No you didn't.  You waffled.  The answer is a simple yes or no
    since you
    have either accepted that you were wrong before or you have not.

    But we know the answer because you have invented a whole swathe of >>>>>> made-up terms in order to try to hide what you were once happy to be >>>>>> clear about: that you consider the wrong answer to be the right one. >>>>>>
    Of course, being clear about that meant you were in danger of being >>>>>> ignored (no one cares about the problem that is not the halting
    problem), so you stared a long campaign of waffling.  You've used >>>>>> ever
    more obtuse phrasing in an attempt to make it /less/ clear, but I
    remember when you were not being so coy about it.

    (A) You are not talking about the halting problem because you accept >>>>>>      false as the correct answer for at least one halting
    computation.

    (B) You are not talking about Turing machines because you assert that >>>>>>      two identical collections of states and associated transition >>>>>>      clauses can transition to different states when given the >>>>>> same tape
         input.

    Apart from A and B, you are bang on track!


    Actually, he's been explicit that he isn't working on the Halting
    problem by his statement that H applied <H^> <H^> isn't required to
    answer about the behavior of H^ applied to <H^> which a Halt
    Decider is.

    He isn't just giving a wrong answer, he claims his answer isn't
    based on the mapping that a Halt Decider is supposed to be computing. >>>>>

    Try and find a consensus of computer scientists that disagree that:

    (a) A decider computes the mapping from its inputs to a final accept
    or reject state.

    (b) A halt decider is a decider.


    No complaints about that, the issue is that a Halt Decider needs to
    compute the Halting function which is the mapping of the behavior of
    the machine that its input represents.
    The way that you use the term "Represents" diverges from "specifies".

    When a policeman interviews Sam to see if Bill was at Sam's house last
    night between 8:00 PM and 10:00 PM if Sam says yes on the basis that
    Bill's lawyer (that represents Bill) was at his house, Sam made a
    false police report and can go to jail.

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

    The actual behavior that an input pair specifies is determined by the
    simulation of this input pair at the Ĥ.qx point in the execution trace.


    The DEFINITION of a Halt Decider:

    H applied to <M> w is to go to H.Qy is M applied to w will halt and to
    H.Qn if M applied to w will never halt.

    DO YOU ACCEPT THAT DEFINITION?
    That one is always correct except in the case of pathological self
    reference (Olcott 2004).

    This one is always correct even in the case of pathological self
    reference (Olcott 2004):

    Simple English version of Olcott's Halt status criterion measure:
    Every simulating halt decider that must abort the simulation of its
    input to prevent its infinite simulation correctly transitions to its
    reject state.

    Somewhat formalized version of Olcott's Halt status criterion measure:
    Let ⟨M⟩ describe a Turing machine M = (Q, Σ, Γ, δ, q₀, □, F), and let w
    be any element of Σ⁺, A solution of the halting problem is a Turing
    machine H, which for any ⟨M⟩ and w, performs the computation (Linz 1990:317)

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
    state of M

    Simulating halt decider H performs a pure simulation of its input as if
    it was a UTM unless and until it detects an infinitely repeating
    pattern. Then it aborts the simulation of its input and transitions to
    its final reject state. Otherwise H transitions to its accept state when
    its simulation ends.


    --
    Copyright 2021 Pete 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 Richard Damon on Sat Feb 19 13:57:24 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 1:48 PM, Richard Damon wrote:
    On 2/19/22 2:08 PM, olcott wrote:
    On 2/19/2022 12:55 PM, Richard Damon wrote:
    On 2/19/22 1:07 PM, olcott wrote:
    On 2/19/2022 11:45 AM, Richard Damon wrote:

    On 2/19/22 12:36 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    I provided the answer via all of the reasoning that derives the
    answer.

    No you didn't.  You waffled.  The answer is a simple yes or no
    since you
    have either accepted that you were wrong before or you have not.

    But we know the answer because you have invented a whole swathe of >>>>>> made-up terms in order to try to hide what you were once happy to be >>>>>> clear about: that you consider the wrong answer to be the right one. >>>>>>
    Of course, being clear about that meant you were in danger of being >>>>>> ignored (no one cares about the problem that is not the halting
    problem), so you stared a long campaign of waffling.  You've used >>>>>> ever
    more obtuse phrasing in an attempt to make it /less/ clear, but I
    remember when you were not being so coy about it.

    (A) You are not talking about the halting problem because you accept >>>>>>      false as the correct answer for at least one halting
    computation.

    (B) You are not talking about Turing machines because you assert that >>>>>>      two identical collections of states and associated transition >>>>>>      clauses can transition to different states when given the >>>>>> same tape
         input.

    Apart from A and B, you are bang on track!


    Actually, he's been explicit that he isn't working on the Halting
    problem by his statement that H applied <H^> <H^> isn't required to
    answer about the behavior of H^ applied to <H^> which a Halt
    Decider is.

    He isn't just giving a wrong answer, he claims his answer isn't
    based on the mapping that a Halt Decider is supposed to be computing. >>>>>

    Try and find a consensus of computer scientists that disagree that:

    (a) A decider computes the mapping from its inputs to a final accept
    or reject state.

    (b) A halt decider is a decider.


    No complaints about that, the issue is that a Halt Decider needs to
    compute the Halting function which is the mapping of the behavior of
    the machine that its input represents.
    The way that you use the term "Represents" diverges from "specifies".

    When a policeman interviews Sam to see if Bill was at Sam's house last
    night between 8:00 PM and 10:00 PM if Sam says yes on the basis that
    Bill's lawyer (that represents Bill) was at his house, Sam made a
    false police report and can go to jail.

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

    The actual behavior that an input pair specifies is determined by the
    simulation of this input pair at the Ĥ.qx point in the execution trace.


    The DEFINITION of a Halt Decider:

    H applied to <M> w is to go to H.Qy is M applied to w will halt and to
    H.Qn if M applied to w will never halt.

    DO YOU ACCEPT THAT DEFINITION?
    That one is always correct except in the case of pathological self
    reference (Olcott 2004).

    This one is always correct even in the case of pathological self
    reference (Olcott 2004):

    Simple English version of Olcott's Halt status criterion measure:
    Every simulating halt decider that must abort the simulation of its
    input to prevent its infinite simulation correctly transitions to its
    reject state.

    Somewhat formalized version of Olcott's Halt status criterion measure:
    Let ⟨M⟩ describe a Turing machine M = (Q, Σ, Γ, δ, q₀, □, F), and let w
    be any element of Σ⁺, A solution of the halting problem is a Turing
    machine H, which for any ⟨M⟩ and w, performs the computation (Linz 1990:317)

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
    state of M

    Simulating halt decider H performs a pure simulation of its input as if
    it was a UTM unless and until it detects an infinitely repeating
    pattern. Then it aborts the simulation of its input and transitions to
    its final reject state. Otherwise H transitions to its accept state when
    its simulation ends.


    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sat Feb 19 14:46:10 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 2:38 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/19/2022 11:36 AM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
    H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final state of M

    RHS is a paraphrase of Ben Bacarisse encoding of my halt status >>>>>>>>>> criterion measure.

    I never encoded your "halt status criterion measure" so you can not be
    paraphrasing such a thing here. I re-wrote Linz's condition in terms of
    a UTM.

    That is exactly the same thing that I am referring to.

    Are you reneging on the silly claim that false (or reject) is the correct
    answer for at least one halting computation? A direct answer would be >>>>>>> appreciated.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    No answer to my direct question (I didn't expect one -- the answer is >>>>> embarrassing to you).

    The copy of H at Ĥ.qx will be referred to as embedded_H.
    No answer to my question.

    Because simulating halt deciders are deciders they are only
    accountable for computing the mapping from their finite string pair** >>>>>> inputs to an accept or reject state entirely on the basis of the
    whether or not their pure simulation of this input pair would ever >>>>>> reach its own final state.
    Still no answer.

    ** (Turing machine description / finite string)

    Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
    final state of ⟨Ĥ⟩.qn in any finite number of simulated steps >>>>>> embedded_H is necessarily correct to transition to Ĥ.qn.
    Still no answer.

    embedded_H is not accountable for reporting on the behavior of the >>>>>> computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not
    an actual input and deciders are only accountable for computing the >>>>>> mapping from their inputs to an accept / reject state.
    Still no answer.

    I provided the answer via all of the reasoning that derives the
    answer.
    No you didn't. You waffled. The answer is a simple yes or no since you >>> have either accepted that you were wrong before or you have not.

    A simple yes or no is far too easy to reject out-of-hand without
    review.

    And it would embarrass you. You'd either have to admit to being wrong
    for years, or you'd have to admit that are still not talking about the halting problem.

    By the way, only one answer can be rejected out of hand. If you have
    not changed your mind about what the right answer is for the key
    computation, then, yes, there is nothing more to say. But if you accept
    that you've been wrong about that for years, a very great deal of
    reviewing should be done.

    (A) You are not talking about the halting problem because you accept
    false as the correct answer for at least one halting computation.
    (B) You are not talking about Turing machines because you assert that
    two identical collections of states and associated transition
    clauses can transition to different states when given the same tape >>> input.
    Apart from A and B, you are bang on track!

    It is clear that you made sure to ignore every single word that I said
    and/or are simply totally ignorant of the fact that all deciders
    compute the mapping from their inputs to an accept or reject state.

    Do you dispute either of these? I can provide citations (you know I
    can, even if you don't know what an NTTP message ID is).


    A PhD computer scientist just agreed: Deciders compute the mapping from
    their inputs to an accept or reject state.

    From this we know that halt deciders compute the mapping from their
    finite string input pair to an accept/reject state.

    We can add to this the self-evident truth that they compute this mapping
    on the basis of the behavior specified by this finite string pair.

    YOU DON'T SEEM TO BE ABLE TO COMPREHEND THIS:
    YOU DON'T SEEM TO BE ABLE TO COMPREHEND THIS:
    YOU DON'T SEEM TO BE ABLE TO COMPREHEND THIS:

    From this we can conclude that the behavior of non-inputs is totally irrelevant to any halt status decision.

    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sat Feb 19 14:36:51 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 2:29 PM, Ben Bacarisse wrote:
    Richard Damon <Richard@Damon-Family.org> writes:

    On 2/19/22 12:36 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    I provided the answer via all of the reasoning that derives the
    answer.
    No you didn't. You waffled. The answer is a simple yes or no since you >>> have either accepted that you were wrong before or you have not.
    But we know the answer because you have invented a whole swathe of
    made-up terms in order to try to hide what you were once happy to be
    clear about: that you consider the wrong answer to be the right one.
    Of course, being clear about that meant you were in danger of being
    ignored (no one cares about the problem that is not the halting
    problem), so you stared a long campaign of waffling. You've used ever
    more obtuse phrasing in an attempt to make it /less/ clear, but I
    remember when you were not being so coy about it.
    (A) You are not talking about the halting problem because you accept
    false as the correct answer for at least one halting computation.
    (B) You are not talking about Turing machines because you assert that
    two identical collections of states and associated transition
    clauses can transition to different states when given the same tape >>> input.
    Apart from A and B, you are bang on track!

    Actually, he's been explicit that he isn't working on the Halting
    problem by his statement that H applied <H^> <H^> isn't required to
    answer about the behavior of H^ applied to <H^> which a Halt Decider
    is.

    The facts are all there, I agree, but there's a fog of words around it designed to make it less then explicit. At least it's not what I'd call explicit. Good technical writing does not pussy-foot about with phrases
    like "on the basis of" and "accountable for". Nor does it make use of extensive subjunctives and pronouns with ambiguous referents.

    Explicit is:

    "In this paper I redefine what it means for a computation to halt.
    I call this PO-halting. Some halting computations will be defined
    to be non-PO-halting; specifically those where a related computation
    (using a simulation) do not halt. A formal definition is given in
    section 1."

    He isn't just giving a wrong answer, he claims his answer isn't based
    on the mapping that a Halt Decider is supposed to be computing.

    I think he's been much clearer in that past. All the recent posts have
    been abut generating exactly the right kind of fog.

    If H isn't 'responsible' for computing the mapping of <M> w to Y or N,
    based on the behavir of of M applied to w Halting or not, H isn't a
    Halt Decider.

    The word responsible is not a technical term. That's deliberate. He
    can then argue about words and not about why he's wrong.


    Deciders only compute the mapping from their actual inputs to accept or
    reject state. Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to the halt status decision because it is not an actual input.

    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sat Feb 19 17:15:13 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Deciders only compute the mapping from their actual inputs to accept
    or reject state.

    Too many words. Deciders accept or reject any and all inputs.


    My words are precisely technically accurate.

    Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
    the halt status decision because it is not an actual input.

    This is so silly. I tried to help once by suggesting you to specify a
    much simpler TM, but you don't like being given helpful exercises.

    Except for the most trivial examples, TMs are always specified in terms
    of what the input encodes, rather than what the "actual input" is.


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

    The key distinction is that the exact point of the execution trace matters.

    A simulation of the input by the copy of H embedded at Ĥ.qx cannot
    possibly ever reach its final state of ⟨Ĥ⟩.qn in any finite number of steps.

    The fact that when embedded_H transitions to Ĥ.qn Ĥ applied to ⟨Ĥ⟩ halts does not contradict the fact that the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H species a non-halting sequence of configurations.

    For anyone not allergic to the facts, the conditions for a halt decider
    can be written in any of these forms:

    H x y ⊦* qy if x encodes a TM M such that M halts in input y
    H x y ⊦* qn otherwise

    H x y ⊦* qy if UTM(x,y) halts
    H x y ⊦* qn otherwise

    H <M> y ⊦* qy if UTM(<M>,y) halts
    H <M> y ⊦* qn otherwise

    H <M> y ⊦* qy if M halts in input y
    H <M> y ⊦* qn otherwise

    They are all equivalent. They are all different to your made up
    "criterion".



    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sat Feb 19 18:02:17 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 5:20 PM, Ben Bacarisse wrote:
    Richard Damon <Richard@Damon-Family.org> writes:

    On 2/19/22 1:52 PM, olcott wrote:

    I just found a PhD computer scientist that agreed.

    So, is he someone that anyone Knows? I know a lot of PhD's who don't
    actually know Jack Shit about their field.

    Usenet cranks appear to be obsessed with PhDs. If I were writing a
    crank score card, mention of PhDs would be an instant +10.

    I once shared a cubicle with a CS PhD student who was developing a
    notation (and a database) for recording traditional Scottish country
    dances. And he got his PhD (though heaven knows how they found an
    external examiner), but he did not know one end of a Turing machine from another.

    Now I come to think if it, another +10 on the crank score would come
    from challenging critics to agree with statements not in dispute.


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

    Because all simulating halt deciders are deciders that compute the
    mapping from their input finite strings to an accept or reject state
    anything that is not any input (such as the behavior of Ĥ applied to
    ⟨Ĥ⟩) is totally irrelevant to the halt status decision.

    Is the reason that you do not critique this because you do not
    understand the words?

    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sat Feb 19 19:04:30 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Is the reason that you do not critique this because you do not
    understand the words?

    Until you correct your two huge mistakes (not talking about the halting problem and not talking about Turing machines) there is not point it critiquing anything you say.

    Even Linz was confused by the fact that a halt decider is a decider thus
    only computes the mapping of its inputs to an accept or reject state

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.


    --
    Copyright 2021 Pete 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 Richard Damon on Sat Feb 19 19:56:02 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 7:23 PM, Richard Damon wrote:

    On 2/19/22 8:04 PM, olcott wrote:
    On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Is the reason that you do not critique this because you do not
    understand the words?

    Until you correct your two huge mistakes (not talking about the halting
    problem and not talking about Turing machines) there is not point it
    critiquing anything you say.

    Even Linz was confused by the fact that a halt decider is a decider
    thus only computes the mapping of its inputs to an accept or reject state

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.


    No, he was NOT confused. That IS the definition of a Halt Decider.

    It decides if the Actual Machine given the actual input will Halt.

    Except for the case of pathological self-reference Olcott(2004) it makes
    no difference whether or not H computes the halt status on the basis of
    whether or not its simulation of its input would ever reach the final
    state of this input or computes it on the basis the the direct execution
    of the machine on its input halts.

    Because no one has ever noticed that it makes a difference these two
    things have always been conflated together as equivalent.


    --
    Copyright 2021 Pete 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 Richard Damon on Sat Feb 19 22:07:39 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 8:15 PM, Richard Damon wrote:
    On 2/19/22 8:56 PM, olcott wrote:
    On 2/19/2022 7:23 PM, Richard Damon wrote:

    On 2/19/22 8:04 PM, olcott wrote:
    On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Is the reason that you do not critique this because you do not
    understand the words?

    Until you correct your two huge mistakes (not talking about the
    halting
    problem and not talking about Turing machines) there is not point it >>>>> critiquing anything you say.

    Even Linz was confused by the fact that a halt decider is a decider
    thus only computes the mapping of its inputs to an accept or reject
    state

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
    EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
    EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
    EMBEDDED_H.


    No, he was NOT confused. That IS the definition of a Halt Decider.

    It decides if the Actual Machine given the actual input will Halt.

    Except for the case of pathological self-reference Olcott(2004) it
    makes no difference whether or not H computes the halt status on the
    basis of whether or not its simulation of its input would ever reach
    the final state of this input or computes it on the basis the the
    direct execution of the machine on its input halts.

    Because no one has ever noticed that it makes a difference these two
    things have always been conflated together as equivalent.



    The Definitino IS the Definition.

    There is no 'pathological' exception.

    YOU are just WRONG.

    That is the simple meaning of the words as defined by the field.

    You have no power to change them, only to LIE by using wrong one.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    embedded_H is the copy of Linz H at Ĥ.qx.

    The meaning of the technical terms of the field specify that because the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H cannot possibly reach its final state of ⟨Ĥ⟩.qn in any finite number of simulated steps this input specifies a non-halting sequence of configurations.

    The meaning of the technical terms of the field also specify that
    because a decider only computes the mapping from its inputs to a final
    accept or reject state, that non-inputs have no bearing on the
    correctness of any halt status decision.

    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sun Feb 20 10:06:20 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Deciders only compute the mapping from their actual inputs to accept
    or reject state.
    Too many words. Deciders accept or reject any and all inputs.

    My words are precisely technically accurate.

    There are just too many of them. Waffle is not always wrong. You think using lots of words makes you sound all technical and "sciency", but
    that's because you've not spent much time around smart technical people.

    Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
    the halt status decision because it is not an actual input.

    This is so silly. I tried to help once by suggesting you to specify a
    much simpler TM, but you don't like being given helpful exercises.
    Except for the most trivial examples, TMs are always specified in terms
    of what the input encodes, rather than what the "actual input" is.

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

    The key distinction is that the exact point of the execution trace
    matters.

    No, that's your big mistake (B). For Turing machines, all that matters
    is the state and the tape, and that's what those lines you keep writing specify. H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
    transitions to qn.


    How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ ?
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    The behavior of Ĥ ⟨Ĥ⟩ depends on the behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input


    --
    Copyright 2021 Pete 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 Richard Damon on Sun Feb 20 10:01:55 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/19/2022 8:15 PM, Richard Damon wrote:
    On 2/19/22 8:56 PM, olcott wrote:
    On 2/19/2022 7:23 PM, Richard Damon wrote:

    On 2/19/22 8:04 PM, olcott wrote:
    On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Is the reason that you do not critique this because you do not
    understand the words?

    Until you correct your two huge mistakes (not talking about the
    halting
    problem and not talking about Turing machines) there is not point it >>>>> critiquing anything you say.

    Even Linz was confused by the fact that a halt decider is a decider
    thus only computes the mapping of its inputs to an accept or reject
    state

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
    EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
    EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
    EMBEDDED_H.


    No, he was NOT confused. That IS the definition of a Halt Decider.

    It decides if the Actual Machine given the actual input will Halt.

    Except for the case of pathological self-reference Olcott(2004) it
    makes no difference whether or not H computes the halt status on the
    basis of whether or not its simulation of its input would ever reach
    the final state of this input or computes it on the basis the the
    direct execution of the machine on its input halts.

    Because no one has ever noticed that it makes a difference these two
    things have always been conflated together as equivalent.



    The Definitino IS the Definition.

    There is no 'pathological' exception.

    YOU are just WRONG.

    That is the simple meaning of the words as defined by the field.

    How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    The behavior of Ĥ ⟨Ĥ⟩ depends on the behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input

    --
    Copyright 2021 Pete 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 M Kfivethousand on Sun Feb 20 21:14:03 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/20/2022 3:55 PM, M Kfivethousand wrote:
    On Saturday, February 19, 2022 at 12:55:23 PM UTC-6, richar...@gmail.com wrote:
    On 2/19/22 1:07 PM, olcott wrote:
    On 2/19/2022 11:45 AM, Richard Damon wrote:

    On 2/19/22 12:36 PM, Ben Bacarisse wrote:
    olcott <polc...@gmail.com> writes:

    I provided the answer via all of the reasoning that derives the
    answer.

    No you didn't. You waffled. The answer is a simple yes or no since you >>>>> have either accepted that you were wrong before or you have not.

    But we know the answer because you have invented a whole swathe of
    made-up terms in order to try to hide what you were once happy to be >>>>> clear about: that you consider the wrong answer to be the right one. >>>>>
    Of course, being clear about that meant you were in danger of being
    ignored (no one cares about the problem that is not the halting
    problem), so you stared a long campaign of waffling. You've used ever >>>>> more obtuse phrasing in an attempt to make it /less/ clear, but I
    remember when you were not being so coy about it.

    (A) You are not talking about the halting problem because you accept >>>>> false as the correct answer for at least one halting computation. >>>>>
    (B) You are not talking about Turing machines because you assert that >>>>> two identical collections of states and associated transition
    clauses can transition to different states when given the same tape >>>>> input.

    Apart from A and B, you are bang on track!


    Actually, he's been explicit that he isn't working on the Halting
    problem by his statement that H applied <H^> <H^> isn't required to
    answer about the behavior of H^ applied to <H^> which a Halt Decider is. >>>>
    He isn't just giving a wrong answer, he claims his answer isn't based
    on the mapping that a Halt Decider is supposed to be computing.


    Try and find a consensus of computer scientists that disagree that:

    (a) A decider computes the mapping from its inputs to a final accept or
    reject state.

    (b) A halt decider is a decider.

    No complaints about that, the issue is that a Halt Decider needs to
    compute the Halting function which is the mapping of the behavior of the
    machine that its input represents. Thus H applied to <H^> <H^> needs to
    produce the same result as the function Halting(H^ applied to <H^>) so
    while you say that H isn't 'responsible' for that, it is.

    Note, the behavior of H^ applied to <H^> is fully obtainable from <H^>
    <H^> as it will be the same as UTM(<H^>,<H^>), the only issue is that H
    can't just be a UTM, as it needs to answer quicker than a UTM for the
    non-halting case, but this shows that there DOES exist a mapping from
    the input to H to what H is supposed to generate (just that the mapping
    might not be finite computable).

    he has to figure out how to assemble it first. Bet he never does that though)

    mk5000

    I already did that first: https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2


    He confronted the senators with the fact that members of their own body, motivated by opportunistic desires to win the emperor’s favor, had denounced other members. Furthermore, they themselves had pronounced the sentences of death against their
    colleagues. --― Aloys Winterling, Caligula: A Biography


    --
    Copyright 2021 Pete 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 Richard Damon on Mon Feb 21 09:18:21 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/20/2022 9:24 PM, Richard Damon wrote:
    On 2/20/22 10:14 PM, olcott wrote:
    On 2/20/2022 3:55 PM, M Kfivethousand wrote:
    On Saturday, February 19, 2022 at 12:55:23 PM UTC-6,
    richar...@gmail.com wrote:
    On 2/19/22 1:07 PM, olcott wrote:
    On 2/19/2022 11:45 AM, Richard Damon wrote:

    On 2/19/22 12:36 PM, Ben Bacarisse wrote:
    olcott <polc...@gmail.com> writes:

    I provided the answer via all of the reasoning that derives the >>>>>>>> answer.

    No you didn't.  You waffled.  The answer is a simple yes or no >>>>>>> since you
    have either accepted that you were wrong before or you have not. >>>>>>>
    But we know the answer because you have invented a whole swathe of >>>>>>> made-up terms in order to try to hide what you were once happy to be >>>>>>> clear about: that you consider the wrong answer to be the right one. >>>>>>>
    Of course, being clear about that meant you were in danger of being >>>>>>> ignored (no one cares about the problem that is not the halting
    problem), so you stared a long campaign of waffling.  You've used >>>>>>> ever
    more obtuse phrasing in an attempt to make it /less/ clear, but I >>>>>>> remember when you were not being so coy about it.

    (A) You are not talking about the halting problem because you accept >>>>>>>       false as the correct answer for at least one halting
    computation.

    (B) You are not talking about Turing machines because you assert >>>>>>> that
          two identical collections of states and associated transition
          clauses can transition to different states when given the >>>>>>> same tape
          input.

    Apart from A and B, you are bang on track!


    Actually, he's been explicit that he isn't working on the Halting
    problem by his statement that H applied <H^> <H^> isn't required to >>>>>> answer about the behavior of H^ applied to <H^> which a Halt
    Decider is.

    He isn't just giving a wrong answer, he claims his answer isn't based >>>>>> on the mapping that a Halt Decider is supposed to be computing.


    Try and find a consensus of computer scientists that disagree that:

    (a) A decider computes the mapping from its inputs to a final
    accept or
    reject state.

    (b) A halt decider is a decider.

    No complaints about that, the issue is that a Halt Decider needs to
    compute the Halting function which is the mapping of the behavior of
    the
    machine that its input represents. Thus H applied to <H^> <H^> needs to >>>> produce the same result as the function Halting(H^ applied to <H^>) so >>>> while you say that H isn't 'responsible' for that, it is.

    Note, the behavior of H^ applied to <H^> is fully obtainable from <H^> >>>> <H^> as it will be the same as UTM(<H^>,<H^>), the only issue is that H >>>> can't just be a UTM, as it needs to answer quicker than a UTM for the
    non-halting case, but this shows that there DOES exist a mapping from
    the input to H to what H is supposed to generate (just that the mapping >>>> might not be finite computable).

    he has to figure out how to assemble it first. Bet he never does that
    though)

    mk5000

    I already did that first:
    https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2



    Which has been show to have more errors than you could shake a stick at.

    Including things like the H ian't actualy looking at the description of
    H^,
    I am referring to the C/x86 analysis of H and P, not the analysis of the
    copy of H at Ĥ.qx applied to the Turing machine descriptions of ⟨Ĥ⟩ ⟨Ĥ⟩.

    --
    Copyright 2021 Pete 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 Richard Damon on Mon Feb 21 09:23:10 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/20/2022 11:29 AM, Richard Damon wrote:
    On 2/20/22 11:06 AM, olcott wrote:
    On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Deciders only compute the mapping from their actual inputs to accept >>>>>> or reject state.
    Too many words.  Deciders accept or reject any and all inputs.

    My words are precisely technically accurate.

    There are just too many of them.  Waffle is not always wrong.  You think >>> using lots of words makes you sound all technical and "sciency", but
    that's because you've not spent much time around smart technical people. >>>
    Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
    the halt status decision because it is not an actual input.

    This is so silly.  I tried to help once by suggesting you to specify a >>>>> much simpler TM, but you don't like being given helpful exercises.
    Except for the most trivial examples, TMs are always specified in
    terms
    of what the input encodes, rather than what the "actual input" is.

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

    The key distinction is that the exact point of the execution trace
    matters.

    No, that's your big mistake (B).  For Turing machines, all that matters >>> is the state and the tape, and that's what those lines you keep writing
    specify.  H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
    transitions to qn.


    How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ ?
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    The behavior of Ĥ ⟨Ĥ⟩ depends on the behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input


    The behavior of embedded_H <H^> <H^> depends on the input <H^> <H^>
    which depend on the machine H^ which depends on the behavior of H so the cycle is complete.


    This is not true.

    The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input.
    embedded_H is not allowed to report on the behavior of the computation
    that contains itself: Ĥ ⟨Ĥ⟩ because this computation IS NOT AN INPUT TO embedded_H. Halt deciders are only allowed to report on the behavior of
    their actual inputs. (Even Linz missed this key detail).

    Yes, embedded_H/H don't directly execute H^ to get the bahavior, but
    simulate the description, but the results of the simulation still must matchthe behavior of the simulation or representation were incorect (and
    you provided both, so YOU are incorrrect).

    FAIL.



    --
    Copyright 2021 Pete 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 Richard Damon on Mon Feb 21 09:34:08 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/20/2022 11:26 AM, Richard Damon wrote:
    On 2/20/22 11:01 AM, olcott wrote:
    On 2/19/2022 8:15 PM, Richard Damon wrote:
    On 2/19/22 8:56 PM, olcott wrote:
    On 2/19/2022 7:23 PM, Richard Damon wrote:

    On 2/19/22 8:04 PM, olcott wrote:
    On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Is the reason that you do not critique this because you do not >>>>>>>> understand the words?

    Until you correct your two huge mistakes (not talking about the
    halting
    problem and not talking about Turing machines) there is not point it >>>>>>> critiquing anything you say.

    Even Linz was confused by the fact that a halt decider is a
    decider thus only computes the mapping of its inputs to an accept
    or reject state

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR >>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO >>>>>> EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR >>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO >>>>>> EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR >>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO >>>>>> EMBEDDED_H.


    No, he was NOT confused. That IS the definition of a Halt Decider.

    It decides if the Actual Machine given the actual input will Halt.

    Except for the case of pathological self-reference Olcott(2004) it
    makes no difference whether or not H computes the halt status on the
    basis of whether or not its simulation of its input would ever reach
    the final state of this input or computes it on the basis the the
    direct execution of the machine on its input halts.

    Because no one has ever noticed that it makes a difference these two
    things have always been conflated together as equivalent.



    The Definitino IS the Definition.

    There is no 'pathological' exception.

    YOU are just WRONG.

    That is the simple meaning of the words as defined by the field.

    How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    The behavior of Ĥ ⟨Ĥ⟩ depends on the behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input


    But the simulation of <H^> <H^> depends on the behavior of H^ which
    depends on the behaviot of H (BY DEFINITION).


    THE MEANING OF THESE WORDS PROVE THAT THEY ARE TRUE
    THE MEANING OF THESE WORDS PROVE THAT THEY ARE TRUE
    THE MEANING OF THESE WORDS PROVE THAT THEY ARE TRUE

    The definition of a decider is that it computes the mapping from its
    inputs to an accept/reject state. It is dishonest for you to reject this because you know its true.

    It is also dishonest for you to construe Ĥ ⟨Ĥ⟩ as an input to embedded_H because you know that the computation that contains embedded_H cannot be
    an input to embedded_H. TM's cannot take other TM's as inputs, they must
    have finite string TM descriptions.

    WHY LIE ?

    So the dependency works both ways.

    IF the behavior of H^ applied to <H^> differs from the behavior of the simulation of <H^> <H^>, then BY DEFINITION, the simulation is incorrect.

    THE DEFINITION of simualtion by a UTM is that the simulation EXACTLY
    matches the behavior of the machine it is simulating the representation of.

    THis is actually a fundamental principle of simulation in general.

    So, your argument has just FAILED>


    --
    Copyright 2021 Pete 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 Richard Damon on Mon Feb 21 09:36:21 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/20/2022 5:43 AM, Richard Damon wrote:
    On 2/19/22 11:51 PM, olcott wrote:
    On 2/19/2022 10:38 PM, Richard Damon wrote:

    On 2/19/22 11:07 PM, olcott wrote:
    On 2/19/2022 8:15 PM, Richard Damon wrote:
    On 2/19/22 8:56 PM, olcott wrote:
    On 2/19/2022 7:23 PM, Richard Damon wrote:

    On 2/19/22 8:04 PM, olcott wrote:
    On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Is the reason that you do not critique this because you do not >>>>>>>>>> understand the words?

    Until you correct your two huge mistakes (not talking about the >>>>>>>>> halting
    problem and not talking about Turing machines) there is not
    point it
    critiquing anything you say.

    Even Linz was confused by the fact that a halt decider is a
    decider thus only computes the mapping of its inputs to an
    accept or reject state

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR >>>>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO >>>>>>>> EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR >>>>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO >>>>>>>> EMBEDDED_H.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR >>>>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO >>>>>>>> EMBEDDED_H.


    No, he was NOT confused. That IS the definition of a Halt Decider. >>>>>>>
    It decides if the Actual Machine given the actual input will Halt. >>>>>>
    Except for the case of pathological self-reference Olcott(2004) it >>>>>> makes no difference whether or not H computes the halt status on
    the basis of whether or not its simulation of its input would ever >>>>>> reach the final state of this input or computes it on the basis
    the the direct execution of the machine on its input halts.

    Because no one has ever noticed that it makes a difference these
    two things have always been conflated together as equivalent.



    The Definitino IS the Definition.

    There is no 'pathological' exception.

    YOU are just WRONG.

    That is the simple meaning of the words as defined by the field.

    You have no power to change them, only to LIE by using wrong one.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    embedded_H is the copy of Linz H at Ĥ.qx.

    The meaning of the technical terms of the field specify that because
    the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H cannot possibly
    reach its final state of ⟨Ĥ⟩.qn in any finite number of simulated >>>> steps this input specifies a non-halting sequence of configurations.

    Nope, it isn't that H can't simulate to a final state,

    It is that no correct simulation at Ĥ.qx can simulate ⟨Ĥ⟩ ⟨Ĥ⟩ such
    that it reaches its final state of ⟨Ĥ⟩.qn.



    Which doesn't matter, as that isn't the criteria.

    The criteria is does a correct simulation by a UTM of the input to H
    reach a final state, and it does if H goes to H.Qn.

    Wrongo !!! Any and all correct simulations whether or not performed by
    a UTM equally count as the correct criterion measure.

    --
    Copyright 2021 Pete 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 Ben Bacarisse on Tue Feb 22 21:50:32 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Is the reason that you do not critique this because you do not
    understand the words?
    Until you correct your two huge mistakes (not talking about the halting
    problem and not talking about Turing machines) there is not point it
    critiquing anything you say.

    Even Linz was confused by the fact that a halt decider is a decider
    thus only computes the mapping of its inputs to an accept or reject
    state

    But your mistakes have nothing to do with that. Even if we assume that
    Linz was confused, that does alter a thing I said about (A)
    your not talking about the halting problem because you accept a wrong
    answer as being correct[1], and (B) you are not talking about Turing
    machines because identical PO-machines can transition to different
    states when given the same input.

    You could try to formally define PO-machines so that we could all ignore
    you, or you could try to defined the problem that has false as the
    correct answer for some halting computations, again, so that we could
    ignore you, but neither satisfied. The key thing is that you not be
    ignored so continuing to be wrong is your best option.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
    EMBEDDED_H.

    But who cares?

    For conventional halt deciders defined in terms of conventional deciders
    that fact that

    the input to embedded_H cannot possibly reach its final state of ⟨Ĥ⟩.qn, and is thus specifies a non-halting sequence of configurations.

    This is not contradicted by the fact that Ĥ ⟨Ĥ⟩ halts.

    deciders ONLY compute the mapping from their inputs to an accept /
    reject state.

    Anything that is not an input is OUT-OF-SCOPE FOR EVERY DECIDER.
    Anything that is not an input is OUT-OF-SCOPE FOR EVERY DECIDER.
    Anything that is not an input is OUT-OF-SCOPE FOR EVERY DECIDER.
    Anything that is not an input is OUT-OF-SCOPE FOR EVERY DECIDER.

    H and Ĥ are PO-machines not Turing machines, and H is
    not a halt decider but a decider for some other property no one cares
    about. Obviously you want people to engage with what you say about PO-machines solving the almost-but-not-quite halting problem, but that
    would be a waste of time.

    You need to agree that false (reject) is never the right answer for a
    halting computation, and that two identical state machines go though identical transitions when given identical inputs. Until then, no
    proper communication can occur.

    [1] I note that today you have flipped on what the wrong answer is
    though I bet you don't even know you've done that.



    --
    Copyright 2021 Pete 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 Ben Bacarisse on Tue Feb 22 21:41:53 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Deciders only compute the mapping from their actual inputs to accept >>>>>> or reject state.
    Too many words. Deciders accept or reject any and all inputs.

    My words are precisely technically accurate.
    There are just too many of them. Waffle is not always wrong. You think >>> using lots of words makes you sound all technical and "sciency", but
    that's because you've not spent much time around smart technical people. >>>
    Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
    the halt status decision because it is not an actual input.

    This is so silly. I tried to help once by suggesting you to specify a >>>>> much simpler TM, but you don't like being given helpful exercises.
    Except for the most trivial examples, TMs are always specified in terms >>>>> of what the input encodes, rather than what the "actual input" is.

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

    The key distinction is that the exact point of the execution trace
    matters.

    No, that's your big mistake (B). For Turing machines, all that matters
    is the state and the tape, and that's what those lines you keep writing
    specify. H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
    transitions to qn.

    How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
    ?

    That's not the question. To get out of this hole you need to read what people write and address the points they make.

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

    You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
    same (actually corresponding) states.

    I have reversed my view on this on the basis of a deeper understanding
    of the notion of computable functions.

    That's because your PO-machines
    are magic -- that's your big mistake (B).

    According to Message-ID: <IpmdnfFa7dl5C4j_nZ2dnUU7-L3NnZ2d@giganews.com>

    | ... this never occurs:
    | embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩.qn


    My notational conventions were incorrect.
    Here is the correct way to say that:

    The simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H cannot possibly reach ⟨Ĥ⟩.qn,
    because ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely nested simulation to embedded_H.

    so, in fact, Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.q (and on into a loop). If
    your machines were not magic, H ⟨Ĥ⟩ ⟨Ĥ⟩ would also transitions to (it's)
    qy, meaning that H determines that the computation represented by the
    string ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting one.

    The simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H specifies infinitely nested simulation that never reaches ⟨Ĥ⟩.qn.

    But (again, if these were TMs and not
    magic PO-machines) you have just told us that it is not.

    You've flipped you big mistake (B) -- now you are claiming that true
    (accept) is the correct answer for at least one non-halting computation.


    I am, not doing this.

    --
    Copyright 2021 Pete 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 Ben Bacarisse on Wed Feb 23 18:56:35 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Deciders only compute the mapping from their actual inputs to accept >>>>>>>> or reject state.
    Too many words. Deciders accept or reject any and all inputs.

    My words are precisely technically accurate.
    There are just too many of them. Waffle is not always wrong. You think >>>>> using lots of words makes you sound all technical and "sciency", but >>>>> that's because you've not spent much time around smart technical people. >>>>>
    Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to >>>>>>>> the halt status decision because it is not an actual input.

    This is so silly. I tried to help once by suggesting you to specify a >>>>>>> much simpler TM, but you don't like being given helpful exercises. >>>>>>> Except for the most trivial examples, TMs are always specified in terms >>>>>>> of what the input encodes, rather than what the "actual input" is. >>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    The key distinction is that the exact point of the execution trace >>>>>> matters.

    No, that's your big mistake (B). For Turing machines, all that matters >>>>> is the state and the tape, and that's what those lines you keep writing >>>>> specify. H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
    transitions to qn.

    How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
    ?
    That's not the question. To get out of this hole you need to read what
    people write and address the points they make.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
    same (actually corresponding) states.

    I have reversed my view on this on the basis of a deeper understanding
    of the notion of computable functions.

    Everyone else knew it from understanding what a Turing machine is, but
    kudos to you for (almost) saying you were wrong.


    I was shocked to find out that a Turing machine cannot do what every C
    program can do because TM's only implement computable functions.

    I wonder, though, if you actually accept the truth: that ether

    H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy

    or

    H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    As soon as H or embedded_H sees a machine with an identical finite
    string TM description simulated twice with the same input it rejects.


    I hope so.

    According to Message-ID: <IpmdnfFa7dl5C4j_nZ2dnUU7-L3NnZ2d@giganews.com> >>> | ... this never occurs:
    | embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩.qn

    My notational conventions were incorrect.

    Admitting two mistakes in one post.

    Now all you need to do is agree that false (or reject) is never the
    correct answer for a halting computation and there can be a reasoned
    debate about why no Turing machines computes the halting function.


    If you would bother to pay attention to what I am saying rather than
    simply always consistently reject what I say out-of-hand without review,
    then you would realize that my completely reconfigured analysis is
    clearly correct.

    --
    Copyright 2021 Pete 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 Ben Bacarisse on Wed Feb 23 19:06:22 2022
    XPost: comp.theory, sci.logic, sci.logic

    On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Is the reason that you do not critique this because you do not
    understand the words?
    Until you correct your two huge mistakes (not talking about the halting >>>>> problem and not talking about Turing machines) there is not point it >>>>> critiquing anything you say.

    Even Linz was confused by the fact that a halt decider is a decider
    thus only computes the mapping of its inputs to an accept or reject
    state
    But your mistakes have nothing to do with that. Even if we assume that
    Linz was confused, that does alter a thing I said about (A)
    your not talking about the halting problem because you accept a wrong
    answer as being correct[1], and (B) you are not talking about Turing
    machines because identical PO-machines can transition to different
    states when given the same input.
    You could try to formally define PO-machines so that we could all ignore >>> you, or you could try to defined the problem that has false as the
    correct answer for some halting computations, again, so that we could
    ignore you, but neither satisfied. The key thing is that you not be
    ignored so continuing to be wrong is your best option.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
    EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
    EMBEDDED_H.

    But who cares?

    For conventional halt deciders...

    There are none. There are multiple proofs to that effect. Your unconventional "halt decider" is permitted to get some answer wrong.
    It's that that no one cares about.

    There is no dispute (from either of us) on these facts. What you call a "conventional" halt decider must return false only for non-halting computations but you declare that to be correct for at least one halting computation. You are ruling yourself out of the debate.

    You have been 100% that you are not talking about "conventional"
    halting. You can rejoin the debate about halting at any time by simply acknowledging that redefining the problem was a silly idea.

    I note elsewhere that you have (almost) admitted to being wrong about
    big mistake (B) so you are very nearly talking about the same thing as
    Linz and Sipser and Kleene and Turing and the world. Just (A) to
    correct.


    You still have not noticed that Ĥ applied to ⟨Ĥ⟩ cannot possibly have
    any relevance to the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ because
    all deciders only apply to their actual inputs thus anything that is not
    an input (such as Ĥ applied to ⟨Ĥ⟩) is out-of-scope.

    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sat Feb 26 19:03:20 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/26/2022 6:33 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Is the reason that you do not critique this because you do not >>>>>>>> understand the words?
    Until you correct your two huge mistakes (not talking about the halting >>>>>>> problem and not talking about Turing machines) there is not point it >>>>>>> critiquing anything you say.

    Even Linz was confused by the fact that a halt decider is a decider >>>>>> thus only computes the mapping of its inputs to an accept or reject >>>>>> state
    But your mistakes have nothing to do with that. Even if we assume that >>>>> Linz was confused, that does alter a thing I said about (A)
    your not talking about the halting problem because you accept a wrong >>>>> answer as being correct[1], and (B) you are not talking about Turing >>>>> machines because identical PO-machines can transition to different
    states when given the same input.
    You could try to formally define PO-machines so that we could all ignore >>>>> you, or you could try to defined the problem that has false as the
    correct answer for some halting computations, again, so that we could >>>>> ignore you, but neither satisfied. The key thing is that you not be >>>>> ignored so continuing to be wrong is your best option.

    THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR >>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO >>>>>> EMBEDDED_H.

    But who cares?

    For conventional halt deciders...
    There are none. There are multiple proofs to that effect. Your
    unconventional "halt decider" is permitted to get some answer wrong.

    It's that that no one cares about.

    There is no dispute (from either of us) on these facts. What you
    call a "conventional" halt decider must return false only for
    non-halting computations but you declare that to be correct for at
    least one halting computation. You are ruling yourself out of the
    debate. You have been 100% that you are not talking about
    "conventional" halting. You can rejoin the debate about halting at
    any time by simply acknowledging that redefining the problem was a
    silly idea. I note elsewhere that you have (almost) admitted to
    being wrong about big mistake (B) so you are very nearly talking
    about the same thing as Linz and Sipser and Kleene and Turing and the
    world. Just (A) to correct.

    You still have not noticed that Ĥ applied to ⟨Ĥ⟩ cannot possibly have >> any relevance to the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
    because all deciders only apply to their actual inputs thus anything
    that is not an input (such as Ĥ applied to ⟨Ĥ⟩) is out-of-scope.

    You don't know what the halting function is. What Ĥ applied to ⟨Ĥ⟩ does
    is the /only/ thing that determines what embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ should do.

    Even Linz was confused by this. embedded_H is not supposed to report on
    itself or the computation that it is contained within.

    Because all halt deciders are deciders that compute the mapping from
    their inputs to an accept or reject state they are only allowed to
    report on the actual behavior of their actual input.

    Any opinion about what the behavior should be is utterly superseded by
    what this behavior actually is. The actual behavior is specified by the
    pure simulation of the finite string pair by embedded_H.

    If this simulation proves that no number of finite steps of pure
    simulation ever reach a final state of the simulated input (AKA the
    simulation only stops when it is aborted) then that proves that the
    finite string pair specify a non-halting sequence of configurations.


    I think you know this. That's why you always, deceptively, remove the
    key criteria for H, and Ĥ, to behave as defined by Linz:

    H x y |-* qn if x encodes a TM that does not halt on input y
    H ⟨Ĥ⟩ ⟨Ĥ⟩ |-* qn if ⟨Ĥ⟩ encodes a TM that does not halt on input ⟨Ĥ⟩

    Now that you have accepted that H ⟨Ĥ⟩ ⟨Ĥ⟩ and embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ must
    preform the same sequence of transitions (up to qn or qy) you should
    also accept that

    Ĥ ⟨Ĥ⟩ |-* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ |-* qn
    if ⟨Ĥ⟩ encodes a TM that does not halt on input ⟨Ĥ⟩.

    ⟨Ĥ⟩, of course, encodes the TM Ĥ, and Ĥ halts on input ⟨Ĥ⟩.

    At some level I suspect you know this. If you did not, there would be
    no reason to make the silly decision to state that the wrong answer is
    the right one. If you do not see that no TM is correct about every
    input case, why just not state that "your" H does indeed compute the
    halting function? No, your "adapted criterion" is there precisely
    because you know the actual criterion (does M halt in input I) is not computable.



    --
    Copyright 2021 Pete 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 Ben Bacarisse on Sat Feb 26 19:16:16 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/26/2022 6:34 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
    olcott <NoOne@NoWhere.com> writes:

    On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Deciders only compute the mapping from their actual inputs to accept >>>>>>>>>> or reject state.
    Too many words. Deciders accept or reject any and all inputs. >>>>>>>>
    My words are precisely technically accurate.
    There are just too many of them. Waffle is not always wrong. You think
    using lots of words makes you sound all technical and "sciency", but >>>>>>> that's because you've not spent much time around smart technical people.

    Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to >>>>>>>>>> the halt status decision because it is not an actual input. >>>>>>>>>
    This is so silly. I tried to help once by suggesting you to specify a
    much simpler TM, but you don't like being given helpful exercises. >>>>>>>>> Except for the most trivial examples, TMs are always specified in terms
    of what the input encodes, rather than what the "actual input" is. >>>>>>>>
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    The key distinction is that the exact point of the execution trace >>>>>>>> matters.

    No, that's your big mistake (B). For Turing machines, all that matters >>>>>>> is the state and the tape, and that's what those lines you keep writing >>>>>>> specify. H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
    transitions to qn.

    How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
    ?
    That's not the question. To get out of this hole you need to read what >>>>> people write and address the points they make.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
    same (actually corresponding) states.

    I have reversed my view on this on the basis of a deeper understanding >>>> of the notion of computable functions.
    Everyone else knew it from understanding what a Turing machine is, but
    kudos to you for (almost) saying you were wrong.


    I was shocked to find out that a Turing machine cannot do what every C
    program can do because TM's only implement computable functions.

    Really? Did you think a TM could let you post to Usenet? Maybe after,
    a few decades of pontificating about them, you will eventually know what Turing machines are.


    The common understanding of Church-Turing is that whatever any computer
    can do a Turing machine can do.

    I wonder, though, if you actually accept the truth: that ether
    H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
    or
    H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    As soon as H or embedded_H sees a machine with an identical finite
    string TM description simulated twice with the same input it rejects.

    So you agree with Linz that Ĥ ⟨Ĥ⟩ halts even though (indeed, because!) H
    rejects ⟨Ĥ⟩ ⟨Ĥ⟩. That is consistent with your major mistake: that you
    are not talking about computing the halting function. Linz reaches a different conclusion because his H /is/ supposed to compute the halting function.


    embedded_H does compute the halting function of its inputs. It
    transitions to its reject state entirely on the basis that its pure
    simulation of its inputs would never reach their final state.

    This proves that embedded_H correctly rejects its input in the same way
    that having a black cat proves that you have a cat.

    My reasoning above is airtight.

    If you have a black cat and the mathematics of computable functions says
    that you don't have a cat then the math is simply wrong.

    There's nothing more to say about the matter since you don't dispute the
    fact that you have declared false (or reject) to be the correct answer
    for at least one halting computation.

    If you would bother to pay attention to what I am saying rather than
    simply always consistently reject what I say out-of-hand without
    review, then you would realize that my completely reconfigured
    analysis is clearly correct.

    You have not changed our mind that false/reject is the correct answer
    for at least one halting computation. Do let the world know when you
    are prepared to discuss the halting problem.



    --
    Copyright 2021 Pete 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 Ben Bacarisse on Mon Feb 28 10:10:37 2022
    XPost: comp.theory, sci.logic, sci.math

    On 2/28/2022 8:50 AM, Ben Bacarisse wrote:
    olcott <polcott2@gmail.com> writes:

    Even Linz was confused by this. embedded_H is not supposed to report
    on itself or the computation that it is contained within.

    No one thinks it should. You don't know what Linz says even after all
    these years. If you want to know what Linz says, I am open to pertinent questions on the topic.


    You for one have insisted that it should as your primary rebuttal to my
    work for six straight months.

    The computation the embedded_H is contained within is: Ĥ ⟨Ĥ⟩

    The fact that embedded_H correctly determines that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts then transitions to Ĥ.qn causing both itself and Ĥ ⟨Ĥ⟩ to halt was always presented as contradicting the verified fact that the
    simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

    The fact that overrides this rebuttal is that a halt decider only
    computes the mapping from its inputs to an accept or reject state making
    the behavior of every non-input such as Ĥ ⟨Ĥ⟩ out-of-scope for embedded_H.

    --
    Copyright 2021 Pete 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)