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.
On 2/19/22 9:24 AM, olcott wrote:Because simulating halt deciders are deciders they are only accountable
On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:I provided the answer via all of the reasoning that derives the answer.
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.
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.
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.
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
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.
olcott <polcott2@gmail.com> writes:
On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:I provided the answer via all of the reasoning that derives the
On 2/18/2022 9:28 PM, Ben Bacarisse wrote:No answer to my direct question (I didn't expect one -- the answer is
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
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 onlyStill no answer.
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)Still no answer.
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 theStill no answer.
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.
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!
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.
On 2/19/22 1:07 PM, olcott wrote:The way that you use the term "Represents" diverges from "specifies".
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.
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.
On 2/19/22 2:08 PM, olcott wrote:That one is always correct except in the case of pathological self
On 2/19/2022 12:55 PM, Richard Damon wrote:
On 2/19/22 1:07 PM, olcott wrote:The way that you use the term "Represents" diverges from "specifies".
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.
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?
On 2/19/22 2:08 PM, olcott wrote:That one is always correct except in the case of pathological self
On 2/19/2022 12:55 PM, Richard Damon wrote:
On 2/19/22 1:07 PM, olcott wrote:The way that you use the term "Represents" diverges from "specifies".
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.
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?
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: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.
olcott <NoOne@NoWhere.com> writes:I provided the answer via all of the reasoning that derives the
On 2/18/2022 9:28 PM, Ben Bacarisse wrote:No answer to my direct question (I didn't expect one -- the answer is >>>>> embarrassing to you).
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.No answer to my question.
Because simulating halt deciders are deciders they are onlyStill no answer.
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)Still no answer.
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 notStill no answer.
an actual input and deciders are only accountable for computing the >>>>>> mapping from their inputs to an accept / reject state.
answer.
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).
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 theNo 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.
answer.
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.
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.
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.
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".
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.
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.
On 2/19/22 8:04 PM, olcott wrote:
On 2/19/2022 6:45 PM, Ben Bacarisse wrote:No, he was NOT confused. That IS the definition of a Halt Decider.
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.
It decides if the Actual Machine given the actual input will Halt.
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:No, he was NOT confused. That IS the definition of a Halt Decider.
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.
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.
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 acceptToo many words. Deciders accept or reject any and all inputs.
or reject state.
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.
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:No, he was NOT confused. That IS the definition of a Halt Decider.
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.
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.
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:No complaints about that, the issue is that a Halt Decider needs to
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.
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
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 theircolleagues. --― Aloys Winterling, Caligula: A Biography
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:No complaints about that, the issue is that a Halt Decider needs to
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.
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.I am referring to the C/x86 analysis of H and P, not the analysis of the
Including things like the H ian't actualy looking at the description of
H^,
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.
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.
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:No, he was NOT confused. That IS the definition of a Halt Decider.
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.
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).
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>
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:Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
On 2/19/2022 7:23 PM, Richard Damon wrote:
Except for the case of pathological self-reference Olcott(2004) it >>>>>> makes no difference whether or not H computes the halt status on
On 2/19/22 8:04 PM, olcott wrote:
On 2/19/2022 6:45 PM, Ben Bacarisse wrote:No, he was NOT confused. That IS the definition of a Halt Decider. >>>>>>>
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.
It decides if the Actual Machine given the actual input will Halt. >>>>>>
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 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.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.
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 notUntil you correct your two huge mistakes (not talking about the halting
understand the words?
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?
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.
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: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
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.
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.
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
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.
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.
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:That's not the question. To get out of this hole you need to read what
olcott <NoOne@NoWhere.com> writes:
On 2/19/2022 4:59 PM, Ben Bacarisse wrote: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. >>>>>
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.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞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 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.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 ⟨Ĥ⟩ ⟨Ĥ⟩
?
people write and address the points they make.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
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 wonder, though, if you actually accept the truth: that ether
H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
or
H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
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.
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:But your mistakes have nothing to do with that. Even if we assume that
olcott <polcott2@gmail.com> writes:
Is the reason that you do not critique this because you do notUntil 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.
understand the words?
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
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.
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:There are none. There are multiple proofs to that effect. Your
olcott <NoOne@NoWhere.com> writes:
On 2/19/2022 6:45 PM, Ben Bacarisse wrote: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)
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
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...
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.
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.
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:Everyone else knew it from understanding what a Turing machine is, but
olcott <polcott2@gmail.com> writes:
On 2/19/2022 6:33 PM, Ben Bacarisse wrote:That's not the question. To get out of this hole you need to read what >>>>> people write and address the points they make.
olcott <NoOne@NoWhere.com> writes:
On 2/19/2022 4:59 PM, Ben Bacarisse wrote:There are just too many of them. Waffle is not always wrong. You think
olcott <polcott2@gmail.com> writes:My words are precisely technically accurate.
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. >>>>>>>>
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.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞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 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.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 ∞You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
same (actually corresponding) states.
I have reversed my view on this on the basis of a deeper understanding >>>> of the notion of computable functions.
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.
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.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 126:06:20 |
| Calls: | 6,663 |
| Calls today: | 1 |
| Files: | 12,212 |
| Messages: | 5,334,951 |