On 1/31/22 11:42 PM, olcott wrote:
On 1/31/2022 10:33 PM, Richard Damon wrote:
On 1/31/22 11:24 PM, olcott wrote:
On 1/31/2022 10:17 PM, Richard Damon wrote:
On 1/31/22 10:40 PM, olcott wrote:No that is not it. That is like saying "by definition" Sum(3,5) is
On 1/31/2022 6:41 PM, Richard Damon wrote:
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>These statements need the conditions, that H^ goes to >>>>>>>>>>>>> H^.Qy/H^.Qn iff H goes to that corresponding state.
⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to embedded_H
in the same way that (5,3) is syntactically specified as an >>>>>>>>>>>> input to Sum(5,3)
Right, and the
Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to >>>>>>>>>>>> embedded_H in the same way that (1,2) is NOT syntactically >>>>>>>>>>>> specified as an input to Sum(5,3)
Right, but perhaps you don't understand that from you above >>>>>>>>>>> statement the right answer is based on if UTM(<H^>,<H^>) >>>>>>>>>>> Halts which by the definition of a UTM means if H^ applied to >>>>>>>>>>> <H^> Halts.
The biggest reason for your huge mistakes is that you cannot >>>>>>>>>> stay sharply focused on a single point. It is as if you either >>>>>>>>>> have attention deficit disorder ADD or are addicted to
methamphetamine.
The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H andĤ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.
After we have mutual agreement on this point we will move on >>>>>>>>>> to the points that logically follow from this one.
Holy shit try to post something that makes sense.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Richard does not accept that the input to the copy of Linz H
embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ ⟨Ĥ⟩.
No, but apparently you can't understand actual English words.
The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must
give is based on the behavior of H^ applied to <H^> BECAUSE OF
THE DEFINITION of H.
In other words Sum(3,5) must return the value of Sum(7,8)?
Don't know how you get that from what I said.
Any moron knows that a function is only accountable for its actual >>>>>> inputs.
And the actual input to H is <H^> <H^> which MEANS by the
DEFINITION of the Halting Problem that H is being asked to decide
on the Halting Status of H^ applied to <H^>
being asked about Sum(7,8).
Again your RED HERRING.
H is being asked EXACTLY what it being asked
H wM w -> H.Qy if M applied to w Halts, and H.Qn if it doesn't
AGREED?
No that is wrong. embedded_H is being asked:
Can the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ possibly transition to ⟨Ĥ⟩.qn ?
If you say 'No', then you aren't doing the halting problem, as the requirement I stated is EXACTLY the requirement of the Halting Problem.
On Tuesday, 1 February 2022 at 23:22:32 UTC+8, olcott wrote:
On 1/31/2022 11:25 PM, Richard Damon wrote:
The halting problem is vague on the definition of halting, it includes
On 1/31/22 11:42 PM, olcott wrote:
On 1/31/2022 10:33 PM, Richard Damon wrote:
On 1/31/22 11:24 PM, olcott wrote:
On 1/31/2022 10:17 PM, Richard Damon wrote:
On 1/31/22 10:40 PM, olcott wrote:No that is not it. That is like saying "by definition" Sum(3,5) is >>>>>> being asked about Sum(7,8).
On 1/31/2022 6:41 PM, Richard Damon wrote:
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞These statements need the conditions, that H^ goes to >>>>>>>>>>>>>>> H^.Qy/H^.Qn iff H goes to that corresponding state. >>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>
⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to embedded_H
in the same way that (5,3) is syntactically specified as an >>>>>>>>>>>>>> input to Sum(5,3)
Right, and the
Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to >>>>>>>>>>>>>> embedded_H in the same way that (1,2) is NOT syntactically >>>>>>>>>>>>>> specified as an input to Sum(5,3)
Right, but perhaps you don't understand that from you above >>>>>>>>>>>>> statement the right answer is based on if UTM(<H^>,<H^>) >>>>>>>>>>>>> Halts which by the definition of a UTM means if H^ applied to >>>>>>>>>>>>> <H^> Halts.
The biggest reason for your huge mistakes is that you cannot >>>>>>>>>>>> stay sharply focused on a single point. It is as if you either >>>>>>>>>>>> have attention deficit disorder ADD or are addicted to >>>>>>>>>>>> methamphetamine.
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H and
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.
After we have mutual agreement on this point we will move on >>>>>>>>>>>> to the points that logically follow from this one.
Holy shit try to post something that makes sense.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Richard does not accept that the input to the copy of Linz H >>>>>>>>>> embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ ⟨Ĥ⟩.
No, but apparently you can't understand actual English words. >>>>>>>>>
The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must >>>>>>>>> give is based on the behavior of H^ applied to <H^> BECAUSE OF >>>>>>>>> THE DEFINITION of H.
In other words Sum(3,5) must return the value of Sum(7,8)?
Don't know how you get that from what I said.
Any moron knows that a function is only accountable for its actual >>>>>>>> inputs.
And the actual input to H is <H^> <H^> which MEANS by the
DEFINITION of the Halting Problem that H is being asked to decide >>>>>>> on the Halting Status of H^ applied to <H^>
Again your RED HERRING.
H is being asked EXACTLY what it being asked
H wM w -> H.Qy if M applied to w Halts, and H.Qn if it doesn't
AGREED?
No that is wrong. embedded_H is being asked:
Can the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ possibly transition to ⟨Ĥ⟩.qn ?
If you say 'No', then you aren't doing the halting problem, as the
requirement I stated is EXACTLY the requirement of the Halting Problem.
that a machine has stopped running and that a machine cannot reach its
final state. My definition only includes the latter.
Sounds like a NDTM.
The Halting Problem has a definite, commonly recognized meaning. It refers to a
real machine, no ambiguity, no one can change it, not even Linz.
Your halt-problem is absolutely certain not Linz's, or of any? textbook.
Your claim contradicts experimental truth. Otherwise, show your x86utm operating
system proof. I guess you would say xxx thousands pages, I believe there are only few lines are yours. Show your codes.
The halting problem does not bother to mention the requirement that
because all halt deciders are deciders they are only accountable for
computing the mapping from their finite string inputs to an accept or
reject state on the basis of the actual behavior specified by this input.
The halting problem does not specifically examine simulating halt
deciders, none-the-less the behavior of a correctly simulated machine
description is known to be equivalent to the behavior of the direct
execution of this same machine.
Since a simulating halt decider is merely a UTM for simulated inputs
that reach their final state when a simulating halt decider correctly
determines that its simulated its input cannot possibly reach its final
state this is complete proof that this simulated input never halts.
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
On Tuesday, 1 February 2022 at 23:22:32 UTC+8, olcott wrote:
On 1/31/2022 11:25 PM, Richard Damon wrote:
The halting problem is vague on the definition of halting, it includes
On 1/31/22 11:42 PM, olcott wrote:
On 1/31/2022 10:33 PM, Richard Damon wrote:
On 1/31/22 11:24 PM, olcott wrote:
On 1/31/2022 10:17 PM, Richard Damon wrote:
On 1/31/22 10:40 PM, olcott wrote:No that is not it. That is like saying "by definition" Sum(3,5) is >>>>>> being asked about Sum(7,8).
On 1/31/2022 6:41 PM, Richard Damon wrote:
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞These statements need the conditions, that H^ goes to >>>>>>>>>>>>>>> H^.Qy/H^.Qn iff H goes to that corresponding state. >>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>
⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to embedded_H
in the same way that (5,3) is syntactically specified as an >>>>>>>>>>>>>> input to Sum(5,3)
Right, and the
Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to >>>>>>>>>>>>>> embedded_H in the same way that (1,2) is NOT syntactically >>>>>>>>>>>>>> specified as an input to Sum(5,3)
Right, but perhaps you don't understand that from you above >>>>>>>>>>>>> statement the right answer is based on if UTM(<H^>,<H^>) >>>>>>>>>>>>> Halts which by the definition of a UTM means if H^ applied to >>>>>>>>>>>>> <H^> Halts.
The biggest reason for your huge mistakes is that you cannot >>>>>>>>>>>> stay sharply focused on a single point. It is as if you either >>>>>>>>>>>> have attention deficit disorder ADD or are addicted to >>>>>>>>>>>> methamphetamine.
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H and
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.
After we have mutual agreement on this point we will move on >>>>>>>>>>>> to the points that logically follow from this one.
Holy shit try to post something that makes sense.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Richard does not accept that the input to the copy of Linz H >>>>>>>>>> embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ ⟨Ĥ⟩.
No, but apparently you can't understand actual English words. >>>>>>>>>
The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must >>>>>>>>> give is based on the behavior of H^ applied to <H^> BECAUSE OF >>>>>>>>> THE DEFINITION of H.
In other words Sum(3,5) must return the value of Sum(7,8)?
Don't know how you get that from what I said.
Any moron knows that a function is only accountable for its actual >>>>>>>> inputs.
And the actual input to H is <H^> <H^> which MEANS by the
DEFINITION of the Halting Problem that H is being asked to decide >>>>>>> on the Halting Status of H^ applied to <H^>
Again your RED HERRING.
H is being asked EXACTLY what it being asked
H wM w -> H.Qy if M applied to w Halts, and H.Qn if it doesn't
AGREED?
No that is wrong. embedded_H is being asked:
Can the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ possibly transition to ⟨Ĥ⟩.qn ?
If you say 'No', then you aren't doing the halting problem, as the
requirement I stated is EXACTLY the requirement of the Halting Problem.
that a machine has stopped running and that a machine cannot reach its
final state. My definition only includes the latter.
Sounds like a NDTM.
On Wednesday, 2 February 2022 at 02:37:17 UTC+8, olcott wrote:
On 2/1/2022 10:33 AM, wij wrote:
On Tuesday, 1 February 2022 at 23:22:32 UTC+8, olcott wrote:https://en.wikipedia.org/wiki/Nondeterministic_Turing_machine
On 1/31/2022 11:25 PM, Richard Damon wrote:
On 1/31/22 11:42 PM, olcott wrote:
On 1/31/2022 10:33 PM, Richard Damon wrote:
On 1/31/22 11:24 PM, olcott wrote:
On 1/31/2022 10:17 PM, Richard Damon wrote:
On 1/31/22 10:40 PM, olcott wrote:No that is not it. That is like saying "by definition" Sum(3,5) is >>>>>>>> being asked about Sum(7,8).
On 1/31/2022 6:41 PM, Richard Damon wrote:
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞These statements need the conditions, that H^ goes to >>>>>>>>>>>>>>>>> H^.Qy/H^.Qn iff H goes to that corresponding state. >>>>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>
⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to embedded_H
in the same way that (5,3) is syntactically specified as an >>>>>>>>>>>>>>>> input to Sum(5,3)
Right, and the
Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to >>>>>>>>>>>>>>>> embedded_H in the same way that (1,2) is NOT syntactically >>>>>>>>>>>>>>>> specified as an input to Sum(5,3)
Right, but perhaps you don't understand that from you above >>>>>>>>>>>>>>> statement the right answer is based on if UTM(<H^>,<H^>) >>>>>>>>>>>>>>> Halts which by the definition of a UTM means if H^ applied to >>>>>>>>>>>>>>> <H^> Halts.
The biggest reason for your huge mistakes is that you cannot >>>>>>>>>>>>>> stay sharply focused on a single point. It is as if you either >>>>>>>>>>>>>> have attention deficit disorder ADD or are addicted to >>>>>>>>>>>>>> methamphetamine.
The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H andĤ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.
After we have mutual agreement on this point we will move on >>>>>>>>>>>>>> to the points that logically follow from this one. >>>>>>>>>>>>>>
Holy shit try to post something that makes sense.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
Richard does not accept that the input to the copy of Linz H >>>>>>>>>>>> embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ ⟨Ĥ⟩.
No, but apparently you can't understand actual English words. >>>>>>>>>>>
The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must >>>>>>>>>>> give is based on the behavior of H^ applied to <H^> BECAUSE OF >>>>>>>>>>> THE DEFINITION of H.
In other words Sum(3,5) must return the value of Sum(7,8)?
Don't know how you get that from what I said.
Any moron knows that a function is only accountable for its actual >>>>>>>>>> inputs.
And the actual input to H is <H^> <H^> which MEANS by the
DEFINITION of the Halting Problem that H is being asked to decide >>>>>>>>> on the Halting Status of H^ applied to <H^>
Again your RED HERRING.
H is being asked EXACTLY what it being asked
H wM w -> H.Qy if M applied to w Halts, and H.Qn if it doesn't
AGREED?
No that is wrong. embedded_H is being asked:
Can the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ possibly transition to ⟨Ĥ⟩.qn ?
If you say 'No', then you aren't doing the halting problem, as the
requirement I stated is EXACTLY the requirement of the Halting Problem. >>>> The halting problem is vague on the definition of halting, it includes >>>> that a machine has stopped running and that a machine cannot reach its >>>> final state. My definition only includes the latter.
Sounds like a NDTM.
It is not a NDTM, a Turing Machine only actually halts when it reaches
its own final state. People not very familiar with this material may get
confused and believe that a TM halts when its stops running because its
simulation has been aborted. This key distinction is not typically
specified in most halting problem proofs.
computation that halts … the Turing machine will halt whenever it enters >> a final state. (Linz:1990:234)
Where did Linz mention 'simulation' and 'abort'?
You are defining POOP [Richard Damon]
André had recommended many online sites for you to learn or test, I forget which posts it is.
But I think C program is more simpler.
Halting problem undecidability and infinitely nested simulation (V3)
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
On 2/1/22 10:22 AM, olcott wrote:
On 1/31/2022 11:25 PM, Richard Damon wrote:
On 1/31/22 11:42 PM, olcott wrote:
On 1/31/2022 10:33 PM, Richard Damon wrote:
On 1/31/22 11:24 PM, olcott wrote:
On 1/31/2022 10:17 PM, Richard Damon wrote:
On 1/31/22 10:40 PM, olcott wrote:No that is not it. That is like saying "by definition" Sum(3,5) is >>>>>> being asked about Sum(7,8).
On 1/31/2022 6:41 PM, Richard Damon wrote:
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞These statements need the conditions, that H^ goes to >>>>>>>>>>>>>>> H^.Qy/H^.Qn iff H goes to that corresponding state. >>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>
⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to >>>>>>>>>>>>>> embedded_H in the same way that (5,3) is syntactically >>>>>>>>>>>>>> specified as an input to Sum(5,3)
Right, and the
Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to >>>>>>>>>>>>>> embedded_H in the same way that (1,2) is NOT syntactically >>>>>>>>>>>>>> specified as an input to Sum(5,3)
Right, but perhaps you don't understand that from you above >>>>>>>>>>>>> statement the right answer is based on if UTM(<H^>,<H^>) >>>>>>>>>>>>> Halts which by the definition of a UTM means if H^ applied >>>>>>>>>>>>> to <H^> Halts.
The biggest reason for your huge mistakes is that you cannot >>>>>>>>>>>> stay sharply focused on a single point. It is as if you >>>>>>>>>>>> either have attention deficit disorder ADD or are addicted >>>>>>>>>>>> to methamphetamine.
The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H andĤ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.
After we have mutual agreement on this point we will move on >>>>>>>>>>>> to the points that logically follow from this one.
Holy shit try to post something that makes sense.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Richard does not accept that the input to the copy of Linz H >>>>>>>>>> embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ ⟨Ĥ⟩.
No, but apparently you can't understand actual English words. >>>>>>>>>
The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must >>>>>>>>> give is based on the behavior of H^ applied to <H^> BECAUSE OF >>>>>>>>> THE DEFINITION of H.
In other words Sum(3,5) must return the value of Sum(7,8)?
Don't know how you get that from what I said.
Any moron knows that a function is only accountable for its
actual inputs.
And the actual input to H is <H^> <H^> which MEANS by the
DEFINITION of the Halting Problem that H is being asked to decide >>>>>>> on the Halting Status of H^ applied to <H^>
Again your RED HERRING.
H is being asked EXACTLY what it being asked
H wM w -> H.Qy if M applied to w Halts, and H.Qn if it doesn't
AGREED?
No that is wrong. embedded_H is being asked:
Can the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ possibly transition to ⟨Ĥ⟩.qn ?
If you say 'No', then you aren't doing the halting problem, as the
requirement I stated is EXACTLY the requirement of the Halting Problem.
The halting problem is vague on the definition of halting, it includes
that a machine has stopped running and that a machine cannot reach its
final state. My definition only includes the latter.
No, it is NOT 'Vague', a machine will EITHER stop running because it
will reach a final state, or it can NEVER reach such a state.
Please show a machine that doesn't reach its final state but also
doesn't run forever?
You seem to think that it is possible for a machine to be in some middle state.
Please provide an example of such a machine.
Note, the definition is stated the way it is because a simulator that
aborts its simulation does NOT indicate either of the cases and does not provide evidence of the Halting state of a computation.
The halting problem does not bother to mention the requirement that
because all halt deciders are deciders they are only accountable for
computing the mapping from their finite string inputs to an accept or
reject state on the basis of the actual behavior specified by this input.
But if they do not compute the mapping per the definition, they are NOT
'Halt Deciders', that is your problem, what you are doing is trying to
define a POOP decider can call it a Halt Decider.
You are not ALLOWED to change the definiton of Halting, when you try, it
just means you logic is unsound and doesn't prove anything, because it
si based on a false premise.
PERIOD.
The halting problem does not specifically examine simulating halt
deciders, none-the-less the behavior of a correctly simulated machine
description is known to be equivalent to the behavior of the direct
execution of this same machine.
Right, NON-ABORTED simuluation, and UNSTOPPED execution. So an H that
aborts or 'debug steps' does NOT prove hon-halting.
PERIOD.
FAIL.
Since a simulating halt decider is merely a UTM for simulated inputs
that reach their final state when a simulating halt decider correctly
determines that its simulated its input cannot possibly reach its
final state this is complete proof that this simulated input never halts.
No, it is NOT a UTM if it aborts its simulation for ANY reason other
than the machine reached a final statee.
Even if it correctly predicts that its input is non-halting, a UTM does
not abort its simulation, as BY DEFINITION, it behaves the same as the machine it is simulating, so if that is non-halting, then the UTM must
be too.
On 2/1/22 4:36 PM, olcott wrote:
On 2/1/2022 3:23 PM, wij wrote:
On Wednesday, 2 February 2022 at 02:37:17 UTC+8, olcott wrote:
On 2/1/2022 10:33 AM, wij wrote:
On Tuesday, 1 February 2022 at 23:22:32 UTC+8, olcott wrote:https://en.wikipedia.org/wiki/Nondeterministic_Turing_machine
On 1/31/2022 11:25 PM, Richard Damon wrote:
The halting problem is vague on the definition of halting, it
On 1/31/22 11:42 PM, olcott wrote:
On 1/31/2022 10:33 PM, Richard Damon wrote:
On 1/31/22 11:24 PM, olcott wrote:
On 1/31/2022 10:17 PM, Richard Damon wrote:
On 1/31/22 10:40 PM, olcott wrote:No that is not it. That is like saying "by definition"
On 1/31/2022 6:41 PM, Richard Damon wrote:Don't know how you get that from what I said.
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
These statements need the conditions, that H^ goes to >>>>>>>>>>>>>>>>>>> H^.Qy/H^.Qn iff H goes to that corresponding state. >>>>>>>>>>>>>>>>>>>
⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to >>>>>>>>>>>>>>>>>> embedded_H
in the same way that (5,3) is syntactically specified >>>>>>>>>>>>>>>>>> as an
input to Sum(5,3)
Right, and the
Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to >>>>>>>>>>>>>>>>>> embedded_H in the same way that (1,2) is NOT >>>>>>>>>>>>>>>>>> syntactically
specified as an input to Sum(5,3)
Right, but perhaps you don't understand that from you >>>>>>>>>>>>>>>>> above
statement the right answer is based on if UTM(<H^>,<H^>) >>>>>>>>>>>>>>>>> Halts which by the definition of a UTM means if H^ >>>>>>>>>>>>>>>>> applied to
<H^> Halts.
The biggest reason for your huge mistakes is that you >>>>>>>>>>>>>>>> cannot
stay sharply focused on a single point. It is as if you >>>>>>>>>>>>>>>> either
have attention deficit disorder ADD or are addicted to >>>>>>>>>>>>>>>> methamphetamine.
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to >>>>>>>>>>>>>>>> embedded_H and
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H. >>>>>>>>>>>>>>>>
After we have mutual agreement on this point we will >>>>>>>>>>>>>>>> move on
to the points that logically follow from this one. >>>>>>>>>>>>>>>>
Holy shit try to post something that makes sense. >>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>
Richard does not accept that the input to the copy of Linz H >>>>>>>>>>>>>> embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is
Ĥ ⟨Ĥ⟩.
No, but apparently you can't understand actual English words. >>>>>>>>>>>>>
The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must >>>>>>>>>>>>> give is based on the behavior of H^ applied to <H^> BECAUSE OF >>>>>>>>>>>>> THE DEFINITION of H.
In other words Sum(3,5) must return the value of Sum(7,8)? >>>>>>>>>>>
Any moron knows that a function is only accountable for its >>>>>>>>>>>> actual
inputs.
And the actual input to H is <H^> <H^> which MEANS by the >>>>>>>>>>> DEFINITION of the Halting Problem that H is being asked to >>>>>>>>>>> decide
on the Halting Status of H^ applied to <H^>
Sum(3,5) is
being asked about Sum(7,8).
Again your RED HERRING.
H is being asked EXACTLY what it being asked
H wM w -> H.Qy if M applied to w Halts, and H.Qn if it doesn't >>>>>>>>>
AGREED?
No that is wrong. embedded_H is being asked:
Can the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ possibly transition to >>>>>>>> ⟨Ĥ⟩.qn ?
If you say 'No', then you aren't doing the halting problem, as the >>>>>>> requirement I stated is EXACTLY the requirement of the Halting
Problem.
includes
that a machine has stopped running and that a machine cannot reach >>>>>> its
final state. My definition only includes the latter.
Sounds like a NDTM.
It is not a NDTM, a Turing Machine only actually halts when it reaches >>>> its own final state. People not very familiar with this material may
get
confused and believe that a TM halts when its stops running because its >>>> simulation has been aborted. This key distinction is not typically
specified in most halting problem proofs.
computation that halts … the Turing machine will halt whenever it
enters
a final state. (Linz:1990:234)
Where did Linz mention 'simulation' and 'abort'?
I have shown how my system directly applies to the actual halting
problem and it can be understood as correct by anyone that understands
the halting problem at a much deeper level than rote memorization.
The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ, it is now a single machine with a single start
state. A copy of Linz H is embedded at Ĥ.qx.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can ⟨Ĥ⟩ applied to ⟨Ĥ⟩ simulated by embedded_H possibly transition to
⟨Ĥ⟩.qn ? (No means that ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt).
But unless embedded_H actually IS a real UTM, that doesn't matter.
On 2/1/22 1:37 PM, olcott wrote:
On 2/1/2022 10:33 AM, wij wrote:
On Tuesday, 1 February 2022 at 23:22:32 UTC+8, olcott wrote:
On 1/31/2022 11:25 PM, Richard Damon wrote:Sounds like a NDTM.
The halting problem is vague on the definition of halting, it includes >>>> that a machine has stopped running and that a machine cannot reach its >>>> final state. My definition only includes the latter.
On 1/31/22 11:42 PM, olcott wrote:
On 1/31/2022 10:33 PM, Richard Damon wrote:
On 1/31/22 11:24 PM, olcott wrote:
On 1/31/2022 10:17 PM, Richard Damon wrote:
On 1/31/22 10:40 PM, olcott wrote:No that is not it. That is like saying "by definition" Sum(3,5) is >>>>>>>> being asked about Sum(7,8).
On 1/31/2022 6:41 PM, Richard Damon wrote:
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞These statements need the conditions, that H^ goes to >>>>>>>>>>>>>>>>> H^.Qy/H^.Qn iff H goes to that corresponding state. >>>>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>>
⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to >>>>>>>>>>>>>>>> embedded_H
in the same way that (5,3) is syntactically specified as an >>>>>>>>>>>>>>>> input to Sum(5,3)
Right, and the
Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to >>>>>>>>>>>>>>>> embedded_H in the same way that (1,2) is NOT syntactically >>>>>>>>>>>>>>>> specified as an input to Sum(5,3)
Right, but perhaps you don't understand that from you above >>>>>>>>>>>>>>> statement the right answer is based on if UTM(<H^>,<H^>) >>>>>>>>>>>>>>> Halts which by the definition of a UTM means if H^ >>>>>>>>>>>>>>> applied to
<H^> Halts.
The biggest reason for your huge mistakes is that you cannot >>>>>>>>>>>>>> stay sharply focused on a single point. It is as if you >>>>>>>>>>>>>> either
have attention deficit disorder ADD or are addicted to >>>>>>>>>>>>>> methamphetamine.
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to >>>>>>>>>>>>>> embedded_H and
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.
After we have mutual agreement on this point we will move on >>>>>>>>>>>>>> to the points that logically follow from this one. >>>>>>>>>>>>>>
Holy shit try to post something that makes sense.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
Richard does not accept that the input to the copy of Linz H >>>>>>>>>>>> embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ
⟨Ĥ⟩.
No, but apparently you can't understand actual English words. >>>>>>>>>>>
The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must >>>>>>>>>>> give is based on the behavior of H^ applied to <H^> BECAUSE OF >>>>>>>>>>> THE DEFINITION of H.
In other words Sum(3,5) must return the value of Sum(7,8)?
Don't know how you get that from what I said.
Any moron knows that a function is only accountable for its >>>>>>>>>> actual
inputs.
And the actual input to H is <H^> <H^> which MEANS by the
DEFINITION of the Halting Problem that H is being asked to decide >>>>>>>>> on the Halting Status of H^ applied to <H^>
Again your RED HERRING.
H is being asked EXACTLY what it being asked
H wM w -> H.Qy if M applied to w Halts, and H.Qn if it doesn't
AGREED?
No that is wrong. embedded_H is being asked:
Can the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ possibly transition to ⟨Ĥ⟩.qn ?
If you say 'No', then you aren't doing the halting problem, as the
requirement I stated is EXACTLY the requirement of the Halting
Problem.
https://en.wikipedia.org/wiki/Nondeterministic_Turing_machine
It is not a NDTM, a Turing Machine only actually halts when it reaches
its own final state. People not very familiar with this material may
get confused and believe that a TM halts when its stops running
because its simulation has been aborted. This key distinction is not
typically specified in most halting problem proofs.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Halting problem undecidability and infinitely nested simulation (V3)
https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3
And the point that you seem to miss is that the Turing Machine doesn't
stop just because some simulation of its representation gave up on
simulating it.
And actual Turing machine will continue to run until it his a final
state or els it will continue to run for an unbounded number of steps.
Non-Halting can only be show by showing that the actual running of the machine will continue for an unbounded number of steps, not just that
there is some N that it doesn't stop in.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 106:16:40 |
| Calls: | 6,661 |
| Calls today: | 3 |
| Files: | 12,209 |
| Messages: | 5,335,403 |