olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 10:36 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 9:39 AM, Ben Bacarisse wrote:But Ĥ is not a Turing machine and ⟨Ĥ⟩ is not a Turing machine
olcott <NoOne@NoWhere.com> writes:
Yet you cannot point out a single error in my halting problemThe mistakes have been pointed out so many times that it's reasonable to >>>>> assume you can't see them or are simply ignoring them. The latest
refutation.
monster error is that if (as you claim) this is true of your Ĥ:
"Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn"
but
"H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
then Ĥ is not even a Truing machine, let alone the specific Ĥ in Linz's >>>>> proof.
If the halt deciding criteria compares the finite strings of Turing
machine descriptions...
Technically Linz refers to a whole class of computations.
No. Linz refer to Turing machine computations. Your PO-machines are
not Turing machines because identical state transition functions entail different configuration sequences for identical inputs.
description. You are not talking about Turing machines. Turing
machines are not magic --
identical state transition functions entail
identical configuration sequences for the identical inputs.
Yes that is correct.
It is for Turing machines, but not your magic PO-machines. This:
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn and H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
is magic, and can't happen if H and H^ are Turing machines. It's odd
that you don't get this. I don't think you have every grasped what a
Turing machine is.
If you start with the foundational assumption that Linz is correct you
can simply assume that my rebuttal is incorrect without even looking
at it.
I start wit the assumption that H is a Turing machine. You start
with the assumption that H is not a Turing machine so sort of magic
thing where an exact copy can entail a different sequence of
transitions.
Note that I am not rebutting anything -- your magic machine may well
have the properties you claim. That's a another question, and one I
don't care about.
you are referring to entities with magic properties. For actual Turing
machines, If Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn then H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qn.
Not when Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn on the basis that Ĥ is invoking an
identical machine description with identical inputs twice in sequence.
If H and Ĥ magic (which is probably what you intend the vague words "on the bases that" to imply) I agree. You machines can do anything you like,
but it says nothing about the proof you think is wrong.
The finite string of ⟨H⟩ is not identical to the finite string of ⟨Ĥ⟩
and the comparison of these finite strings is the halt deciding basis.
If Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn then so does H ⟨Ĥ⟩ ⟨Ĥ⟩ unless H and Ĥ are
not Turing machines.
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 10:36 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 9:39 AM, Ben Bacarisse wrote:But Ĥ is not a Turing machine and ⟨Ĥ⟩ is not a Turing machine
olcott <NoOne@NoWhere.com> writes:
Yet you cannot point out a single error in my halting problemThe mistakes have been pointed out so many times that it's reasonable to >>>>> assume you can't see them or are simply ignoring them. The latest
refutation.
monster error is that if (as you claim) this is true of your Ĥ:
"Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn"
but
"H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
then Ĥ is not even a Truing machine, let alone the specific Ĥ in Linz's >>>>> proof.
If the halt deciding criteria compares the finite strings of Turing
machine descriptions...
Technically Linz refers to a whole class of computations.
No. Linz refer to Turing machine computations. Your PO-machines are
not Turing machines because identical state transition functions entail different configuration sequences for identical inputs.
description. You are not talking about Turing machines. Turing
machines are not magic --
identical state transition functions entail
identical configuration sequences for the identical inputs.
Yes that is correct.
It is for Turing machines, but not your magic PO-machines. This:
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn and H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
is magic, and can't happen if H and H^ are Turing machines. It's odd
that you don't get this. I don't think you have every grasped what a
Turing machine is.
If you start with the foundational assumption that Linz is correct you
can simply assume that my rebuttal is incorrect without even looking
at it.
I start wit the assumption that H is a Turing machine. You start
with the assumption that H is not a Turing machine so sort of magic
thing where an exact copy can entail a different sequence of
transitions.
Note that I am not rebutting anything -- your magic machine may well
have the properties you claim. That's a another question, and one I
don't care about.
you are referring to entities with magic properties. For actual Turing
machines, If Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn then H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qn.
Not when Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn on the basis that Ĥ is invoking an
identical machine description with identical inputs twice in sequence.
If H and Ĥ magic (which is probably what you intend the vague words "on the bases that" to imply) I agree. You machines can do anything you like,
but it says nothing about the proof you think is wrong.
The finite string of ⟨H⟩ is not identical to the finite string of ⟨Ĥ⟩
and the comparison of these finite strings is the halt deciding basis.
If Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn then so does H ⟨Ĥ⟩ ⟨Ĥ⟩ unless H and Ĥ are
not Turing machines.
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must derive the
On 3/22/2022 9:32 AM, Ben Bacarisse wrote:You said this:
olcott <NoOne@NoWhere.com> writes:
On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
olcott <NoOne@NoWhere.com> writes:
A copy of Linz H is embedded at Ĥ.qx as a simulating halt decider (SHD).But for your "PO-machines":
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.
"Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
corresponds to
H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
and
"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
so this has nothing to do with Linz. He is talking about Turing >>>>>>> machines.
The Linz conclusion only pertains to the behavior the copy of H
embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
Everything Linz says, everything, is predicated on what a Turing machine >>>>> is. Unlike Turing machines, your machines are magic -- identical state >>>>> transition functions can entail different configuration sequences for >>>>> the same input. Nothing you say has any relevance to Linz's Turing
machines until you categorically repudiate this nonsense.
That your only rebuttal to what I say now is dredging up what I said
many months ago proves that you are being dishonest.
"The copy of H at Ĥ.qx correctly decides that its input never halts. >>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts" >>
same result. They are not identical final strings.
If H and Ĥ are Turing machines the copy of H at Ĥ.qx cannot make any different transitions than H does, since they both have identical
inputs. If one compares some strings, the other will too and they will
both arrive as the same result and they will both behave in the same
way. You H and Ĥ are obviously not Turing machines.
I regret dropping down into simplistic metaphors. I'd rather keep this
about formal Turing machines, but you don't really know what they are,
and you certainly can't reason about them, so that hits a brick wall
pretty quickly.
four days ago and you haven't retracted it. Until you do, when you
write Ĥ your readers must assume that you are referring to something
about which this quote applies.
What's more, for your remarks to have any bearing on Linz's Ĥ you must
not only repudiate what you said, you must accept the converse,
i.e. that if
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
then
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
So, do you retract what you said and accept this fact about Linz's H and >>> Ĥ?
You you continue to say that you believe that a decider must report on
its own behavior when you already know damn well that a decider only
computes the mapping from its inputs to its own final state.
I continue to believe that I know what a Turing machine is and that you don't. A Turing machine and an exact copy of it can't entail different sequences of transitions. Your H and Ĥ don't have this property. They
are not Turing machines.
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 10:19 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 10:37 PM, Ben Bacarisse wrote:If H and Ĥ are Turing machines the copy of H at Ĥ.qx cannot make any
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 9:32 AM, Ben Bacarisse wrote:You said this:
olcott <NoOne@NoWhere.com> writes:
On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
olcott <NoOne@NoWhere.com> writes:
A copy of Linz H is embedded at Ĥ.qx as a simulating halt decider (SHD).But for your "PO-machines":
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.
"Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
corresponds to
H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
and
"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
so this has nothing to do with Linz. He is talking about Turing >>>>>>>>> machines.
The Linz conclusion only pertains to the behavior the copy of H >>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
Everything Linz says, everything, is predicated on what a Turing machine
is. Unlike Turing machines, your machines are magic -- identical state >>>>>>> transition functions can entail different configuration sequences for >>>>>>> the same input. Nothing you say has any relevance to Linz's Turing >>>>>>> machines until you categorically repudiate this nonsense.
That your only rebuttal to what I say now is dredging up what I said >>>>>> many months ago proves that you are being dishonest.
"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must derive the
same result. They are not identical final strings.
different transitions than H does, since they both have identical
inputs. If one compares some strings, the other will too and they will
both arrive as the same result and they will both behave in the same
way. You H and Ĥ are obviously not Turing machines.
I regret dropping down into simplistic metaphors. I'd rather keep this
about formal Turing machines, but you don't really know what they are,
and you certainly can't reason about them, so that hits a brick wall
pretty quickly.
four days ago and you haven't retracted it. Until you do, when you
write Ĥ your readers must assume that you are referring to something >>>>> about which this quote applies.
What's more, for your remarks to have any bearing on Linz's Ĥ you must >>>>> not only repudiate what you said, you must accept the converse,
i.e. that if
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
then
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
So, do you retract what you said and accept this fact about Linz's H and >>>>> Ĥ?
You you continue to say that you believe that a decider must report on >>>> its own behavior when you already know damn well that a decider only
computes the mapping from its inputs to its own final state.
I continue to believe that I know what a Turing machine is and that you
don't. A Turing machine and an exact copy of it can't entail different
sequences of transitions. Your H and Ĥ don't have this property. They >>> are not Turing machines.
I agree that a TM and an exact copy of it must entail the same
sequence of transitions when applied to identical input.
OK, but what about your magic PO-machines? They don't behave like this (apparently). It's easy to agree to facts about Turing machines, if
your plan is to keep talking about machines where
"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 4:41 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:Not if H and Ĥ are identical and are not allowed to use their machine
On 3/23/2022 10:19 AM, Ben Bacarisse wrote:OK, but what about your magic PO-machines? They don't behave like this
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 10:37 PM, Ben Bacarisse wrote:If H and Ĥ are Turing machines the copy of H at Ĥ.qx cannot make any >>>>> different transitions than H does, since they both have identical
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 9:32 AM, Ben Bacarisse wrote:You said this:
olcott <NoOne@NoWhere.com> writes:
On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
olcott <NoOne@NoWhere.com> writes:
A copy of Linz H is embedded at Ĥ.qx as a simulating halt decider (SHD).But for your "PO-machines":
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.
"Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
corresponds to
H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
and
"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
so this has nothing to do with Linz. He is talking about Turing >>>>>>>>>>> machines.
The Linz conclusion only pertains to the behavior the copy of H >>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
Everything Linz says, everything, is predicated on what a Turing machine
is. Unlike Turing machines, your machines are magic -- identical state
transition functions can entail different configuration sequences for >>>>>>>>> the same input. Nothing you say has any relevance to Linz's Turing >>>>>>>>> machines until you categorically repudiate this nonsense.
That your only rebuttal to what I say now is dredging up what I said >>>>>>>> many months ago proves that you are being dishonest.
"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must derive the
same result. They are not identical final strings.
inputs. If one compares some strings, the other will too and they will >>>>> both arrive as the same result and they will both behave in the same >>>>> way. You H and Ĥ are obviously not Turing machines.
I regret dropping down into simplistic metaphors. I'd rather keep this >>>>> about formal Turing machines, but you don't really know what they are, >>>>> and you certainly can't reason about them, so that hits a brick wall >>>>> pretty quickly.
four days ago and you haven't retracted it. Until you do, when you >>>>>>> write Ĥ your readers must assume that you are referring to something >>>>>>> about which this quote applies.
What's more, for your remarks to have any bearing on Linz's Ĥ you must >>>>>>> not only repudiate what you said, you must accept the converse,
i.e. that if
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
then
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
So, do you retract what you said and accept this fact about Linz's H and
Ĥ?
You you continue to say that you believe that a decider must report on >>>>>> its own behavior when you already know damn well that a decider only >>>>>> computes the mapping from its inputs to its own final state.
I continue to believe that I know what a Turing machine is and that you >>>>> don't. A Turing machine and an exact copy of it can't entail different >>>>> sequences of transitions. Your H and Ĥ don't have this property. They >>>>> are not Turing machines.
I agree that a TM and an exact copy of it must entail the same
sequence of transitions when applied to identical input.
(apparently). It's easy to agree to facts about Turing machines, if
your plan is to keep talking about machines where
"The copy of H at Ĥ.qx correctly decides that its input never halts. >>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts" >>
address to tell them apart.
H and Ĥ are never identical. You know what the hat means don't you? So your magic PO-machines have machine addresses, do they? If so, that's another difference with Turing machines. You won't be able to say
anything about Linz's proof unless you start to talk about Turing
machines.
In my prior claims either H and Ĥ were not identical finite stings
You've lost the plot mate. Nether is even a string. If you made a
prior claim about H or Ĥ being strings (whether identical or not), that
was wrong too.
As far as I can tell, when you write H and Ĥ we must assume that these
refer to some kind of as yet unspecified machine that has "machine
addresses" (so definitely not what Linz is taking about). And that
these H and Ĥ have the property that H applied to some string can
transition to a different state to an exact copy of H if it's embedded
in some other machine. I suppose they don't actually have to be
literally magic to do this, but they are certainly not Turing machines.
Do you have anything to say about Linz's proof?
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 4:41 PM, Ben Bacarisse wrote:H and Ĥ are never identical. You know what the hat means don't you? So >>> your magic PO-machines have machine addresses, do they? If so, that's
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 10:19 AM, Ben Bacarisse wrote:OK, but what about your magic PO-machines? They don't behave like this >>>>> (apparently). It's easy to agree to facts about Turing machines, if >>>>> your plan is to keep talking about machines where
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 10:37 PM, Ben Bacarisse wrote:If H and Ĥ are Turing machines the copy of H at Ĥ.qx cannot make any >>>>>>> different transitions than H does, since they both have identical >>>>>>> inputs. If one compares some strings, the other will too and they will >>>>>>> both arrive as the same result and they will both behave in the same >>>>>>> way. You H and Ĥ are obviously not Turing machines.
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 9:32 AM, Ben Bacarisse wrote:You said this:
olcott <NoOne@NoWhere.com> writes:That your only rebuttal to what I say now is dredging up what I said >>>>>>>>>> many months ago proves that you are being dishonest.
On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
olcott <NoOne@NoWhere.com> writes:
A copy of Linz H is embedded at Ĥ.qx as a simulating halt decider (SHD).But for your "PO-machines":
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.
"Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
corresponds to
H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
and
"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
so this has nothing to do with Linz. He is talking about Turing >>>>>>>>>>>>> machines.
The Linz conclusion only pertains to the behavior the copy of H >>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
Everything Linz says, everything, is predicated on what a Turing machine
is. Unlike Turing machines, your machines are magic -- identical state
transition functions can entail different configuration sequences for
the same input. Nothing you say has any relevance to Linz's Turing >>>>>>>>>>> machines until you categorically repudiate this nonsense. >>>>>>>>>>
"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must derive the
same result. They are not identical final strings.
I regret dropping down into simplistic metaphors. I'd rather keep this >>>>>>> about formal Turing machines, but you don't really know what they are, >>>>>>> and you certainly can't reason about them, so that hits a brick wall >>>>>>> pretty quickly.
four days ago and you haven't retracted it. Until you do, when you >>>>>>>>> write Ĥ your readers must assume that you are referring to something >>>>>>>>> about which this quote applies.
What's more, for your remarks to have any bearing on Linz's Ĥ you must
not only repudiate what you said, you must accept the converse, >>>>>>>>> i.e. that if
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
then
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
So, do you retract what you said and accept this fact about Linz's H and
Ĥ?
You you continue to say that you believe that a decider must report on >>>>>>>> its own behavior when you already know damn well that a decider only >>>>>>>> computes the mapping from its inputs to its own final state.
I continue to believe that I know what a Turing machine is and that you >>>>>>> don't. A Turing machine and an exact copy of it can't entail different >>>>>>> sequences of transitions. Your H and Ĥ don't have this property. They
are not Turing machines.
I agree that a TM and an exact copy of it must entail the same
sequence of transitions when applied to identical input.
"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
Not if H and Ĥ are identical and are not allowed to use their machine >>>> address to tell them apart.
another difference with Turing machines. You won't be able to say
anything about Linz's proof unless you start to talk about Turing
machines.
In my prior claims either H and Ĥ were not identical finite stingsYou've lost the plot mate. Nether is even a string. If you made a
prior claim about H or Ĥ being strings (whether identical or not), that >>> was wrong too.
As far as I can tell, when you write H and Ĥ we must assume that these
refer to some kind of as yet unspecified machine that has "machine
addresses" (so definitely not what Linz is taking about). And that
these H and Ĥ have the property that H applied to some string can
transition to a different state to an exact copy of H if it's embedded
in some other machine. I suppose they don't actually have to be
literally magic to do this, but they are certainly not Turing machines.
Do you have anything to say about Linz's proof?
All halt deciders must map their input to an accept or reject state
based on the actual behavior actually specified by this input as
measured by a finite number of N steps of the correct UTM simulation
of this input.
No. You'll find what a halt decider must do in any good text book.
It appears that after 17 years of work in this you are:
(a) trying to redefine what that halting problem is;
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
As far as I can tell, when you write H and Ĥ we must assume that these >>>>> refer to some kind of as yet unspecified machine that has "machine
addresses" (so definitely not what Linz is taking about). And that
these H and Ĥ have the property that H applied to some string can
transition to a different state to an exact copy of H if it's embedded >>>>> in some other machine. I suppose they don't actually have to be
literally magic to do this, but they are certainly not Turing machines. >>>>> Do you have anything to say about Linz's proof?
All halt deciders must map their input to an accept or reject state
based on the actual behavior actually specified by this input as
measured by a finite number of N steps of the correct UTM simulation
of this input.
No. You'll find what a halt decider must do in any good text book.
It appears that after 17 years of work in this you are:
(a) trying to redefine what that halting problem is;
Someone that understands these things deeper than learned by rote
would agree with me.
No one agrees with the above. It's not the halting problem. What it
is, ironically, is an admission that halting is undecidable! If you
really thought it weren't, there would be no need to keep writing the condition for accepting an input incorrectly.
On 3/24/22 10:50 AM, olcott wrote:
On 3/23/2022 11:21 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
As far as I can tell, when you write H and Ĥ we must assume that >>>>>>> these
refer to some kind of as yet unspecified machine that has "machine >>>>>>> addresses" (so definitely not what Linz is taking about). And that >>>>>>> these H and Ĥ have the property that H applied to some string can >>>>>>> transition to a different state to an exact copy of H if it's
embedded
in some other machine. I suppose they don't actually have to be >>>>>>> literally magic to do this, but they are certainly not Turing
machines.
Do you have anything to say about Linz's proof?
All halt deciders must map their input to an accept or reject state >>>>>> based on the actual behavior actually specified by this input as
measured by a finite number of N steps of the correct UTM simulation >>>>>> of this input.
No. You'll find what a halt decider must do in any good text book. >>>>> It appears that after 17 years of work in this you are:
(a) trying to redefine what that halting problem is;
Someone that understands these things deeper than learned by rote
would agree with me.
No one agrees with the above. It's not the halting problem. What it
is, ironically, is an admission that halting is undecidable! If you
really thought it weren't, there would be no need to keep writing the
condition for accepting an input incorrectly.
Certainly you can state this dogmatically, yet what you cannot do is
anchor this rebuttal in any sort of correct reasoning.
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and
an input, whether the program will finish running, or continue to run
forever. https://en.wikipedia.org/wiki/Halting_problem
A halt decider must map its finite string input pair to an accept or
reject state on the basis of the actual halting / non-halting behavior
specified by this finite string pair.
It is the case that all deciders compute the mapping from their input
finite strings to their own accept or reject state.
It is the case that all deciders compute the mapping from their input
finite strings to their own accept or reject state on the basis of the
behavior specified by these finite strings.
It is the case that the behavior specified by these finite input
strings is correctly measured by the correct UTM simulation of these
strings by the simulating halt decider.
The CORRECT UTM Simulation (not N steps)
On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote:
...[cut]
I would challenge you to try to design a Turing Machine (not just an
'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
its input is a representation of itself. (note, *A*, not *the* as
machines have MANY (infinite) representations of themselves).
That's the point. Not only PO don't have a complete H, he don't have a 'correct'
P either. At most we can see his 'invalid' C implement:
1. H does not exist. P can't exist.
2. The H(P,P) in P should be a 'description' to be a formal proof.
IMO, what PO need is basic logic, otherwise all is meaningless to him.
On 3/24/22 11:15 AM, olcott wrote:
On 3/24/2022 9:58 AM, Richard Damon wrote:
On 3/24/22 10:50 AM, olcott wrote:
On 3/23/2022 11:21 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
As far as I can tell, when you write H and Ĥ we must assume >>>>>>>>> that these
refer to some kind of as yet unspecified machine that has "machine >>>>>>>>> addresses" (so definitely not what Linz is taking about). And >>>>>>>>> that
these H and Ĥ have the property that H applied to some string can >>>>>>>>> transition to a different state to an exact copy of H if it's >>>>>>>>> embedded
in some other machine. I suppose they don't actually have to be >>>>>>>>> literally magic to do this, but they are certainly not Turing >>>>>>>>> machines.
Do you have anything to say about Linz's proof?
All halt deciders must map their input to an accept or reject state >>>>>>>> based on the actual behavior actually specified by this input as >>>>>>>> measured by a finite number of N steps of the correct UTM
simulation
of this input.
No. You'll find what a halt decider must do in any good text book. >>>>>>> It appears that after 17 years of work in this you are:
(a) trying to redefine what that halting problem is;
Someone that understands these things deeper than learned by rote
would agree with me.
No one agrees with the above. It's not the halting problem. What it >>>>> is, ironically, is an admission that halting is undecidable! If you >>>>> really thought it weren't, there would be no need to keep writing the >>>>> condition for accepting an input incorrectly.
Certainly you can state this dogmatically, yet what you cannot do is
anchor this rebuttal in any sort of correct reasoning.
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and
an input, whether the program will finish running, or continue to
run forever. https://en.wikipedia.org/wiki/Halting_problem
A halt decider must map its finite string input pair to an accept or
reject state on the basis of the actual halting / non-halting
behavior specified by this finite string pair.
It is the case that all deciders compute the mapping from their
input finite strings to their own accept or reject state.
It is the case that all deciders compute the mapping from their
input finite strings to their own accept or reject state on the
basis of the behavior specified by these finite strings.
It is the case that the behavior specified by these finite input
strings is correctly measured by the correct UTM simulation of these
strings by the simulating halt decider.
The CORRECT UTM Simulation (not N steps)
This stupidly forbids simulating halt deciders from correctly
rejecting their input. As soon as an infinite behavior pattern is
correctly matched no more steps of simulation need be performed.
You need to CORRECTLY detect infininte behavior, EVEN IF the simulator
aborts is simulation. For many machines, this isn't a problem (it only
does become one if the machine contains a copy of the decider). That is
your failing. Your 'proof' is based on false premises, that the decider
will never abort.
In fact, the bigger issue is that a real Turing Machine H can't actually detect that H^ is using a copy of itself, so it can't detect the
recursion you are detecting. Your claims otherwise just show you don't understand how Turing Machines work.
I would challenge you to try to design a Turing Machine (not just an 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
its input is a representation of itself. (note, *A*, not *the* as
machines have MANY (infinite) representations of themselves).
On Friday, 25 March 2022 at 00:09:19 UTC+8, olcott wrote:
On 3/24/2022 10:58 AM, wij wrote:
On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote: >>>> ...[cut]When you simply assume that H does not exist then it logically follows
I would challenge you to try to design a Turing Machine (not just an
'equivalent, but an ACTUAL Turing Machine) that even trys to detect that >>>> its input is a representation of itself. (note, *A*, not *the* as
machines have MANY (infinite) representations of themselves).
That's the point. Not only PO don't have a complete H, he don't have a 'correct'
P either. At most we can see his 'invalid' C implement:
1. H does not exist. P can't exist.
2. The H(P,P) in P should be a 'description' to be a formal proof.
IMO, what PO need is basic logic, otherwise all is meaningless to him.
that P does not exist. When you look at the actual x86 execution trace
(on pages 4-5) you see that H does correctly determine that its input
never halts and does correctly report this.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
Try replace the call 'H(x,x)' (or TM's codes) in your P with 'description', this
is required by a formal proof.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
On Friday, 25 March 2022 at 01:00:56 UTC+8, olcott wrote:
On 3/24/2022 11:53 AM, wij wrote:
On Friday, 25 March 2022 at 00:09:19 UTC+8, olcott wrote:The x86 machine code of P is a 100% complete machine description of x.
On 3/24/2022 10:58 AM, wij wrote:
On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote: >>>>>> ...[cut]never halts and does correctly report this.
I would challenge you to try to design a Turing Machine (not just an >>>>>> 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that >>>>>> its input is a representation of itself. (note, *A*, not *the* as
machines have MANY (infinite) representations of themselves).
That's the point. Not only PO don't have a complete H, he don't have a 'correct'
P either. At most we can see his 'invalid' C implement:
1. H does not exist. P can't exist.
2. The H(P,P) in P should be a 'description' to be a formal proof.
IMO, what PO need is basic logic, otherwise all is meaningless to him. >>>> When you simply assume that H does not exist then it logically follows >>>> that P does not exist. When you look at the actual x86 execution trace >>>> (on pages 4-5) you see that H does correctly determine that its input
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
Try replace the call 'H(x,x)' (or TM's codes) in your P with 'description', this
is required by a formal proof.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
I mean replace the call 'H(x,x)' with the description (x86 machine code) of H.
It is self-evident that the x86 emulation of the input to H cannot
possibly ever reach its final state of [00000c50].
Yes, I believe a faithful implement cannot reach [00000c50].
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 11:21 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
As far as I can tell, when you write H and Ĥ we must assume that these >>>>>>> refer to some kind of as yet unspecified machine that has "machine >>>>>>> addresses" (so definitely not what Linz is taking about). And that >>>>>>> these H and Ĥ have the property that H applied to some string can >>>>>>> transition to a different state to an exact copy of H if it's embedded >>>>>>> in some other machine. I suppose they don't actually have to be >>>>>>> literally magic to do this, but they are certainly not Turing machines. >>>>>>> Do you have anything to say about Linz's proof?
All halt deciders must map their input to an accept or reject state >>>>>> based on the actual behavior actually specified by this input as
measured by a finite number of N steps of the correct UTM simulation >>>>>> of this input.
No. You'll find what a halt decider must do in any good text book.
It appears that after 17 years of work in this you are:
(a) trying to redefine what that halting problem is;
Someone that understands these things deeper than learned by rote
would agree with me.
No one agrees with the above. It's not the halting problem. What it
is, ironically, is an admission that halting is undecidable! If you
really thought it weren't, there would be no need to keep writing the
condition for accepting an input incorrectly.
Certainly you can state this dogmatically, yet what you cannot do is
anchor this rebuttal in any sort of correct reasoning.
You are impervious to reasoning so I resorted to quoting you. You
explicitly accept reject as the correct "mapping" for a string
representing a halting computation. I'm not sure if there is a
reasoning that could help you here.
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and
an input, whether the program will finish running, or continue to run
forever. https://en.wikipedia.org/wiki/Halting_problem
A halt decider must map its finite string input pair to an accept or
reject state on the basis of the actual halting / non-halting behavior
specified by this finite string pair.
Exactly. Yet you pretend you can't see that declaring reject to be the correct mapping for a string representing a halting computation is
wrong. Do you really think there is anything I could say that would
help you understand?
It is the case that all deciders compute the mapping from their input
finite strings to their own accept or reject state.
Silly wording, but it's not wrong.
It is the case that all deciders compute the mapping from their input
finite strings to their own accept or reject state on the basis of the
behavior specified by these finite strings.
No, but only because you missed out a work. (A decider that accepts
those string the encode prime numbers does not care about the
"behaviour" specified by those strings.)
It is the case that the behavior specified by these finite input
strings is correctly measured by the correct UTM simulation of these
strings by the simulating halt decider.
Indeed. A pointless thing to do but you are obsessed with simulation so
you prefer to write it that way.
It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
embedded_H would never reach its final state.
That's a trick question.
olcott <NoOne@NoWhere.com> writes:
On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to >>>> embedded_H would never reach its final state.
That's a trick question.
Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if >> embedded_H was a UTM then this simulated input would never reach its
final state.
The fact that you keep using ever more vague and hand waving ways to
avoid stating the correct condition should alert everyone to what you
are doing. The correct condition is not about what "would happen if"
things were not as they actually are.
You've been trying this on for months: your Halts function was correct
to reject a halting computation because of what "would happen if" line
15 were commented out (line 15 was the abort that stopped halts from
being a UTM).
olcott <NoOne@NoWhere.com> writes:
On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to >>>>>> embedded_H would never reach its final state.
That's a trick question.
Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if >>>> embedded_H was a UTM then this simulated input would never reach its
final state.
The fact that you keep using ever more vague and hand waving ways to
avoid stating the correct condition should alert everyone to what you
are doing. The correct condition is not about what "would happen if"
things were not as they actually are.
You've been trying this on for months: your Halts function was correct
to reject a halting computation because of what "would happen if" line
15 were commented out (line 15 was the abort that stopped halts from
being a UTM).
I think that the problem is that you really want to disagree at all
costs and that you understood that I am correct many months ago. No
recent rebuttals by anyone have been coherent.
I'll leave that for others to decide, but /you/ are not competent to
assess what I've said. Every time you try to paraphrase my words the
result has been junk (though that might have been deliberate).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 103:30:26 |
| Calls: | 6,660 |
| Calls today: | 2 |
| Files: | 12,209 |
| Messages: | 5,335,074 |