On 12/13/21 8:49 PM, olcott wrote:
On 12/13/2021 7:36 PM, André G. Isaak wrote:
On 2021-12-13 18:09, olcott wrote:
On 12/13/2021 5:40 PM, André G. Isaak wrote:
On 2021-12-13 16:25, olcott wrote:
On 12/13/2021 2:10 PM, André G. Isaak wrote:
On 2021-12-13 11:37, olcott wrote:
On 12/13/2021 12:20 PM, André G. Isaak wrote:OK. So now you've finally gotten that part right.
On 2021-12-13 11:10, olcott wrote:
On 12/13/2021 11:33 AM, André G. Isaak wrote:
On 2021-12-13 09:33, olcott wrote:
On 12/13/2021 10:22 AM, André G. Isaak wrote:
On 2021-12-13 08:50, olcott wrote:
On 12/13/2021 9:24 AM, André G. Isaak wrote:
Your problem is that, despite the fact that you are >>>>>>>>>>>>>>> talking about a theorem which concerns Turing Machines, >>>>>>>>>>>>>>> you continue to think about things in terms of C programs >>>>>>>>>>>>>>> and/or x86 programs which are very different animals from >>>>>>>>>>>>>>> Turing Machines.
As long as a C function is a pure function then it is a >>>>>>>>>>>>>> computable function through the RASP model of computation >>>>>>>>>>>>>> for every input that it derives an output.
No C function is a computable function. Computable
functions are a subset of *mathematical* functions. The >>>>>>>>>>>>> word 'function' in C means something entirely different >>>>>>>>>>>>> than the word 'function' in maths.
A function f with domain D is said to be Turing-computable >>>>>>>>>>>> or just computable if there exists some Turing machine >>>>>>>>>>>> M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F
for all w ∈ D (Linz:1990:243)
Which perfectly agrees with what I just said.
Olcott paraphrase of above machine definition: Machine M >>>>>>>>>>>> begins at start state q0 on input w and transitions to qf as >>>>>>>>>>>> a function of input w.
Which is not a paraphrase of the above.
Linz says that machine M computes the function f(w).Yes, machine M *computes* function f(w). This does not mean >>>>>>>>>>> that machine M is a function. It is not. It is an algorithm. >>>>>>>>>>> The whole point of my post was to try to get you to actually >>>>>>>>>>> grasp the distinction between a function and an algorithm >>>>>>>>>>> which computes that function. The two are not the same thing. >>>>>>>>>>> The terms are not interchangeable. There isn't a one-to-one >>>>>>>>>>> correspondence between the two.
When H(P,P) computes the halting function it is only the
behavior of the actual sequence of configurations specified by >>>>>>>>>> (P,P) as if H was a UTM and not a halt decider that provides >>>>>>>>>> the correct basis for the halt status decision. This is
consistently always the case for every input.
So we're back to the "I don't understand what you wrote so I'll >>>>>>>>> respond with something completely unrelated" approach. Do you >>>>>>>>> know understand the difference between a function and an
algorithm? If so, will you stop misusing them in future?
H is not a computable function H computes the halting function. >>>>>>>
But now you need to think about what that actually *means*
The halting function maps every member of the set of all possible >>>>>>> computation to either 'HALTS' or 'DOESN'T HALT'. Note that this
is simply a mapping. It exists independently of any algorithm
(i.e. halt decider). It has a domain and a codomain. It has no
'inputs' since it is not an algorithm.
H(P,P) computes the halting function for a domain that includes P.
What on earth does that mean?
You don't know what the domain of a function is?
Yes, I do. And P isn't in the domain of the halting function. P(P) is
in its domain but P is not.
The domain of the halting function is the set of all possible
computations.
How many hundreds of times do I have to repeat that I am not solving
the halting problem merely refuting the conventional proofs???
To refute the conventional proofs only requires correctly deciding
the halt status of a single element of the domain of a universal
halt function.
And both P(P) and H_Hat(<H_Hat) *are* in the domain of the halting
function and those are the two elements you claim to be concerned with.
Both of these are mapped to 'HALTS' by the halting function because
the halting function is concerned with how computations behave when
they are actually run.
A computation is a pair of a Turing Machine and an input string. P
isn't such a pair.
H does correctly compute the halt function of its domain and it need
not be a TM.
Because we've observed that P(P) and H_Hat(H_Hat) both halt when >>>>>>> run, it will include P(P) -> HALTS and H_Hat(H_Hat) -> HALTS as
part of its
Neither of those are ACTUAL INPUTS in the domain.
You may think this means something but I can't for the life of me
figure out what it could be. Functions have domains. Turing
Machines have inputs.
Linz says input w is in the domain of f:
A function f with domain D is said to be Turing-computable
or just computable if there exists some Turing machine
M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F
for all w ∈ D (Linz:1990:243)
Sipser says functions have inputs:
A Turing machine computes a function by starting with the input to
the function on the tape and halting with the output of the function
on the tape (Sipser:1997:190).
So when I say that int main() { P(P); } is outside the scope of
computable function H because it is not an input to H I am correct.
Again, what you write is nonsense. P(P) *is* in the domain of the
It looks like both Sipser and Linz correct your "corrections", thus
proving that your "corrections" are incorrect.
The C code that computes the halting function for a domain including
the x86 machine code of the following:
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
void Infinite_Loop(int N)
{
HERE: goto HERE;
}
void Infinite_Recursion(int N)
{
Infinite_Recursion(N);
}
correctly determines that none of the above inputs ever stops running
without being aborted
Except the P(P) does Halt if H(P,P) returns 0.
olcott <NoOne@NoWhere.com> writes:
No matter how you slice it the behavior of Ĥ depends on the decision
of Ĥ.qx
You are talking about TM's again... Let's take a look:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Yup. Since Ĥ.q0 ⟨Ĥ⟩ transitions to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩, what transmissions
follow Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is indeed key (but Ĥ is not a decider, remember).
All you need to do now is explain under which conditions each line
applies and you are done:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
To quote Linz, "this is clearly nonsense".
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 3:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
A function f with domain D is said to be Turing-computable
or just computable if there exists some Turing machine
M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F
for all w ∈ D (Linz:1990:243)
We all know your cut and paste skills are top notch.
Olcott paraphrase of above machine definition: Machine M begins at
start state q0 on input w and transitions to qf as a function of input >>>> w.
But that's not a correct paraphrase.
A Turing machine computes a function by starting with the input to the
function on the tape and halting with the output of the function on
the tape (Sipser:1997:190).
Within the context of the Sipser and Kozen quotes that you erased
exactly how is my paraphrase of Linz incorrect?
Your paraphrase was of the Linz definition. If not, its reference to
q0, qf and w are all wrong. As a paraphrase of Linz, it's wrong because
it substitutes ambiguity for clarity.
To say that M "transitions to qf
as a function of w" is pure waffle.
On 2021-12-18 13:44, olcott wrote:
On 12/18/2021 2:07 PM, Richard Damon wrote:
On 12/18/21 2:28 PM, olcott wrote:
On 12/18/2021 5:06 AM, Richard Damon wrote:
On 12/17/21 11:29 PM, olcott wrote:
On 12/17/2021 10:18 PM, Richard Damon wrote:
On 12/17/21 10:47 PM, olcott wrote:That is under the false assumption that the behavior of the input
On 12/17/2021 9:34 PM, Richard Damon wrote:
On 12/17/21 9:59 PM, olcott wrote:When everyone says
On 12/17/2021 8:44 PM, Richard Damon wrote:
On 12/17/21 9:26 PM, olcott wrote:
On 12/17/2021 7:50 PM, Richard Damon wrote:
On 12/17/21 7:54 PM, olcott wrote:
On 12/17/2021 6:43 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 3:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
A function f with domain D is said to be
Turing-computable
or just computable if there exists some Turing machine >>>>>>>>>>>>>>>>>> M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), >>>>>>>>>>>>>>>>>> qf ∈ F
for all w ∈ D (Linz:1990:243)
We all know your cut and paste skills are top notch. >>>>>>>>>>>>>>>>>
Olcott paraphrase of above machine definition: Machine >>>>>>>>>>>>>>>>>> M begins at
start state q0 on input w and transitions to qf as a >>>>>>>>>>>>>>>>>> function of input
w.
But that's not a correct paraphrase. As for the jumble >>>>>>>>>>>>>>>>> of words that is
"the computable function copy of H at Ĥ.qx", well, I >>>>>>>>>>>>>>>>> despair.
I take this to mean that you have no idea what the >>>>>>>>>>>>>>>> behavior of Ĥ
applied to ⟨Ĥ⟩ would be:
You should, in general, take me to mean what I say, with >>>>>>>>>>>>>>> as little
interpretation as you can muster. Your track record in >>>>>>>>>>>>>>> paraphrasing me
is abysmal. Is my claim that I despair at your jumble of >>>>>>>>>>>>>>> words in some
way unclear?
Since this is equivalent to Linz notation you can't say >>>>>>>>>>>>>> that my question is not clear?
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy >>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>
What would the behavior of Ĥ applied to ⟨Ĥ⟩ be if we >>>>>>>>>>>>>> assume that Ĥ.qx acts exactly as if it was UTM(⟨Ĥ⟩, ⟨Ĥ⟩) ???
So, if you want to DEFINE that you H IS the same as UTM, >>>>>>>>>>>>> then you have shown that H(<H^>,<H^>) nevers returns an >>>>>>>>>>>>> answer, so while H^(<H^>) is FOR THIS H, non-halting, it >>>>>>>>>>>>> doesn't matter as this H never answers, and so it wrong >>>>>>>>>>>>>
Yes that it correct. I don't think that Ben understands >>>>>>>>>>>> these things well enough to understand that.
Hypotheticals which change the contents of H^
All hypotheticals are imaginary and have no effect on the >>>>>>>>>>>> actual world.
(which include its copy of H) don't say anything about the >>>>>>>>>>>>> original H^ that was built from a different H.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ // infinite loop added
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>
When we put the infinite loop back in Ĥ applied to ⟨Ĥ⟩ still >>>>>>>>>>>> never stops running because it still specified infinitely >>>>>>>>>>>> nested simulation. It never reaches the infinite loop.
So, which H do you want to try to claim to be your H, that is >>>>>>>>>>> supposedly correct?
The one that gets stuck in the infinite loop, and thus
doesn't answer, or the one that DOES abort the simulation, >>>>>>>>>>> and thus return the answer to H^ which lets H^ be halting, >>>>>>>>>>> and thus H was wrong?
The fact that for the case that H is identical to UTM gives >>>>>>>>>>>>> a non-halting H^ doesn't provide ANY evidence that H^ built >>>>>>>>>>>>> from an H that answers is non-halting.
When we understand that the hypothetical pure simulation of >>>>>>>>>>>> the input to any simulating halt decider does provide the >>>>>>>>>>>> correct halt status criterion measure for every input then >>>>>>>>>>>> we understand that this is correct: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
No, because H isn't supposed to answer about the
'Hypothetcial' input based on a different H than the one that >>>>>>>>>>> H^ is actually built on, but the actual input that it was >>>>>>>>>>> given which is an H^ built on the H that you claim to be the >>>>>>>>>>> correct answering one.
Any input that must have its simulation aborted to prevent >>>>>>>>>>>> the infinite execution of this input is an input that never >>>>>>>>>>>> halts.
No. Pure LIE.
Halting is based on what the computation ACTUALLY DOES.
No one ever thought this aspect through before. Linz rejects >>>>>>>>>> simulation before ever fully examining it.
No, he doesn't, he doesn't distinguish at all about how the
halt decider works, as it just doesn't matter. All that matters >>>>>>>>> is that H needs to be a DEFINED machine, and he looks at the >>>>>>>>> answer it gives, by how ever it does it.
Every input that never halts when its pure simulation by H >>>>>>>>>> never halts is an input that never halts.
The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its final >>>>>>>>>> state when 0 to ∞ steps of this input are simulated by H. >>>>>>>>>>
But it does when given to a real UTM. UTM applied to <H^> <H^> >>>>>>>>> will halt if H applied to <H^> <H^> goes to H.qn.
You need to FIRST define your H, and once you do you are NOT >>>>>>>>> allowed to change it in determining what H^ does.
Who said H^.qx is applied to H^. WHERE DID I SAY THAT?
Your definition is just how you seem to befine your POOP. >>>>>>>>>>>
LIE.
The meaning of those words proves that those words are correct. >>>>>>>>>>>
The meaning of Halting is that the thing ACTUALLY being
decided on reaches a final Halting state.
Since the ACUTAL H^ applied to <H^> does reach its final >>>>>>>>>>> haltibng state,
Because you know that TM's cannot have TM's for inputs it
seems quite stupid that you say that Ĥ.qx is applied to Ĥ. >>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
Instead of saying
if simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt.
They are saying that Ĥ.qx is being applied to a TM and not a TM >>>>>>>> description.
No, they are appling the definition of a CORRECT Halt Decider.
Ĥ.qx is NOT applied to Ĥ
Ĥ.qx is applied to ⟨Ĥ⟩
Right, but if H is a correcg halt decider (as is your claim) than >>>>>>> H (and just H^.qx) must go to qy if H^ applied to <H^> halts and >>>>>>> to qn if it doesn't.
is the same when executed inside the halt decider as when it is
executed outside the halt decider.
But if they are different, that says that either the decider is NOT
being an accurate simulator or the input is not a representation of
an actual Algorithm.
When the input to H is intentionally defined to have different
behavior inside of H than outside of H then this behavior will
necessarily vary.
But H^ DOESN'T have different behavior inside of H than outside, and
thus neither does its representation.
H^ ALWAYS does the opposite of what the copy of H says it will do,
whether it is being decided by H or not.
The actual behavior of UTM(⟨Ĥ⟩ ⟨Ĥ⟩) of the actual input to to Ĥ.qx is
the only thing that this computable function is accountable for.
Actual computer scientists would know this.
Actual computer scientists would know that the claim that there is a computable function at Ĥ.qx is incoherent nonsense.
André
olcott <NoOne@NoWhere.com> writes:
On 12/18/2021 5:06 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 6:43 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 3:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
A function f with domain D is said to be Turing-computable
or just computable if there exists some Turing machine
M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F >>>>>>>> for all w ∈ D (Linz:1990:243)
We all know your cut and paste skills are top notch.
Olcott paraphrase of above machine definition: Machine M begins at >>>>>>>> start state q0 on input w and transitions to qf as a function of input >>>>>>>> w.
But that's not a correct paraphrase. As for the jumble of words that is
"the computable function copy of H at Ĥ.qx", well, I despair.
I take this to mean that you have no idea what the behavior of Ĥ
applied to ⟨Ĥ⟩ would be:
You should, in general, take me to mean what I say, with as little
interpretation as you can muster. Your track record in paraphrasing me >>>>> is abysmal. Is my claim that I despair at your jumble of words in some >>>>> way unclear?
Since this is equivalent to Linz notation you can't say that my
question is not clear?
You are loosing the plot again. I called out your stupid paraphrase of my >>> words by asking what was unclear about what I'd said.
You, however, are always unclear:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
What would the behavior of Ĥ applied to ⟨Ĥ⟩ be if we assume that Ĥ.qx
acts exactly as if it was UTM(⟨Ĥ⟩, ⟨Ĥ⟩) ???
Here you abuse Linz's hat notation by using it to mean something it does >>> not. Now we have no idea what you mean by Ĥ in any posts form here on
down. So much for you childish repetition, not so very long ago, that
you always mean Linz's Ĥ when you write Ĥ. Not so anymore.
I change one element of Ĥ and ask you to tell me what difference that
makes and you dodge because you simply don't know.
If that makes you feel better, you go right ahead and think that. But remember, from now on you have to say which Ĥ you mean when you write
Ĥ. And you will have to say what H is too since the above Ĥ is built
from a H quite unlike Linz's H.
I'll leave you with the proof in which you have still been unable to
find any flaw. (Yes, I know you point at the last line and SHOUT, but
that's not how mathematics works.)
If a TM, H, existed such that
Hq0 <M> s ⊦* Hqy if M applied to s halts, and
Hq0 <M> s ⊦* Hqn if M applied to s does not halt,
we could construct from it an H' such that
H'q0 <M> s ⊦* oo if M applied to s halts, and
H'q0 <M> s ⊦* H'qn if M applied to s does not halt.
And from that we could construct an Ĥ such that
Ĥq0 <M> ⊦* Ĥqx <M> <M> ⊦* oo if M applied to <M> halts, and
Ĥq0 <M> ⊦* Ĥqx <M> <M> ⊦* Ĥqn if M applied to <M> does not halt.
Setting M to Ĥ, so <M> becomes <Ĥ>, we see that the existence of H (as
Linz defines it) logically entails that a TM Ĥ that does this
Ĥq0 <Ĥ> ⊦* Ĥqx <Ĥ> <Ĥ> ⊦* oo if Ĥ applied to <Ĥ> halts, and
Ĥq0 <Ĥ> ⊦* Ĥqx <Ĥ> <Ĥ> ⊦* Ĥqn if Ĥ applied to <Ĥ> does not halt.
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 3:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
A function f with domain D is said to be Turing-computable
or just computable if there exists some Turing machine
M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* M qf f(w), qf ∈ F >>>> for all w ∈ D (Linz:1990:243)
We all know your cut and paste skills are top notch.
Olcott paraphrase of above machine definition: Machine M begins at
start state q0 on input w and transitions to qf as a function of input >>>> w.
But that's not a correct paraphrase.
A Turing machine computes a function by starting with the input to the
function on the tape and halting with the output of the function on
the tape (Sipser:1997:190).
Within the context of the Sipser and Kozen quotes that you erased
exactly how is my paraphrase of Linz incorrect?
Your paraphrase was of the Linz definition. If not, its reference to
q0, qf and w are all wrong. As a paraphrase of Linz, it's wrong because
it substitutes ambiguity for clarity. To say that M "transitions to qf
as a function of w" is pure waffle.
And you don't say what qf is. If you mention it, you should say why it matters. But you don't need to mention q0. That's just noise, as all
TMs start in their start state, and what it's called it irrelevant to
the paraphrase.
Here's a better paraphrase:
M, given w on its tape, halts with f(w) on the tape, for every string w
in the domain of f.
To say that M "transitions to qf as a function of w" is pure waffle.
But you probably still plan to misuse the term "computable function".
On 12/19/21 12:40 PM, olcott wrote:
On 12/19/2021 10:59 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/18/2021 5:06 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 6:43 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 3:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
I take this to mean that you have no idea what the behavior of Ĥ >>>>>>>> applied to ⟨Ĥ⟩ would be:A function f with domain D is said to be Turing-computable >>>>>>>>>> or just computable if there exists some Turing machine
M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F
for all w ∈ D (Linz:1990:243)
We all know your cut and paste skills are top notch.
Olcott paraphrase of above machine definition: Machine M
begins at
start state q0 on input w and transitions to qf as a function >>>>>>>>>> of input
w.
But that's not a correct paraphrase. As for the jumble of
words that is
"the computable function copy of H at Ĥ.qx", well, I despair. >>>>>>>>
You should, in general, take me to mean what I say, with as little >>>>>>> interpretation as you can muster. Your track record in
paraphrasing me
is abysmal. Is my claim that I despair at your jumble of words >>>>>>> in some
way unclear?
Since this is equivalent to Linz notation you can't say that my
question is not clear?
You are loosing the plot again. I called out your stupid
paraphrase of my
words by asking what was unclear about what I'd said.
You, however, are always unclear:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
What would the behavior of Ĥ applied to ⟨Ĥ⟩ be if we assume that Ĥ.qx
acts exactly as if it was UTM(⟨Ĥ⟩, ⟨Ĥ⟩) ???
Here you abuse Linz's hat notation by using it to mean something it
does
not. Now we have no idea what you mean by Ĥ in any posts form here on >>>>> down. So much for you childish repetition, not so very long ago, that >>>>> you always mean Linz's Ĥ when you write Ĥ. Not so anymore.
I change one element of Ĥ and ask you to tell me what difference that >>>> makes and you dodge because you simply don't know.
If that makes you feel better, you go right ahead and think that. But
remember, from now on you have to say which Ĥ you mean when you write
Ĥ. And you will have to say what H is too since the above Ĥ is built >>> from a H quite unlike Linz's H.
I'll leave you with the proof in which you have still been unable to
find any flaw. (Yes, I know you point at the last line and SHOUT, but
that's not how mathematics works.)
If a TM, H, existed such that
Hq0 <M> s ⊦* Hqy if M applied to s halts, and
Hq0 <M> s ⊦* Hqn if M applied to s does not halt,
we could construct from it an H' such that
H'q0 <M> s ⊦* oo if M applied to s halts, and
H'q0 <M> s ⊦* H'qn if M applied to s does not halt.
And from that we could construct an Ĥ such that
Ĥq0 <M> ⊦* Ĥqx <M> <M> ⊦* oo if M applied to <M> halts, and
Ĥq0 <M> ⊦* Ĥqx <M> <M> ⊦* Ĥqn if M applied to <M> does not halt.
Setting M to Ĥ, so <M> becomes <Ĥ>, we see that the existence of H (as >>> Linz defines it) logically entails that a TM Ĥ that does this
Ĥq0 <Ĥ> ⊦* Ĥqx <Ĥ> <Ĥ> ⊦* oo if Ĥ applied to <Ĥ> halts, and
Ĥq0 <Ĥ> ⊦* Ĥqx <Ĥ> <Ĥ> ⊦* Ĥqn if Ĥ applied to <Ĥ> does not halt.
What is the sequence of configurations specified by Ĥ applied to ⟨Ĥ⟩ >> when we assume that the Linz H is a simulating halt decider and that Ĥ
does not have the infinite loop appended to its Ĥ.qy state?
And what do you mean by H is a simulating Halt Decider?
Have you presumed (as an unproven fact) that H is correct?
It really sounds like you have lost track of the problem you were trying
to solve, and are no longer trying to prove the existence of H by giving
an example, but just ASSUMING it exists and then talking about it, and IGNORING all the contractions its creates or blaming them on H^.
Because H is a simulating halt decider this hypothetical definition of
Ĥ defines H as a pure simulator, thus proving that simulating halt
decider H must abort the simulation of its input.
But a 'Pure Simulator' can't be a Halt Decider, as it can't decide a non-halting pattern, BY DEFINITION.
BY DEFINITION, A 'Pure Simulator' will run forever when its input
represents a non-halting computation, but a Halt Decider, BY DEFINITION,
must return an answer in FINITE time, thus NO 'Pure Simulator' can be a correct Halt Decider.
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
FAIL. You just proved your Halt Decider never answer for this Problem.
On Sunday, 19 December 2021 at 19:04:11 UTC, Jeff Barnett wrote:
On 12/19/2021 11:44 AM, olcott wrote:I think I can answer this for PO.
I can (and will shortly) conclusively prove that pure function HSimple question: Since virtually everyone who has studied this problem
correctly detects that P specifies infinitely nested simulation.
knows, simulation is not a feasible way to build a halt decider
(assuming one could be built). The proof you are attacking as well as
others I am aware of are not based on simulation. Why do insist that
simulation is the way to go?
The first observation is that a simulating halt decider goes into an
infinite series of nested simulations if fed H_Hat. So this leads to the question, can we somehow exploit this to get round the Linz trap?
The answer is "no". But in answering that question, we set up a system
in which the simulating halt decider must get the wrong answer, for reasons which have nothing to do with LInz's "invert the result" step. So have
we broken new ground? Can we maybe say that the result is correct,
because the simulation "aborts" instead of "halting", and if it didn't "abort" it would indeed run forever, so it must have correctly "aborted".
On 12/20/21 10:16 PM, olcott wrote:
On 12/20/2021 8:44 PM, Richard Damon wrote:
On 12/20/21 9:19 PM, olcott wrote:
On 12/20/2021 8:02 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 6:46 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 3:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
A function f with domain D is said to be Turing-computable >>>>>>>>>> or just computable if there exists some Turing machine
M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* M qf f(w), qf ∈ F
for all w ∈ D (Linz:1990:243)
We all know your cut and paste skills are top notch.
Olcott paraphrase of above machine definition: Machine M
begins at
start state q0 on input w and transitions to qf as a function >>>>>>>>>> of input
w.
But that's not a correct paraphrase.
A Turing machine computes a function by starting with the input >>>>>>>> to the
function on the tape and halting with the output of the function on >>>>>>>> the tape (Sipser:1997:190).
Within the context of the Sipser and Kozen quotes that you erased >>>>>>>> exactly how is my paraphrase of Linz incorrect?
Your paraphrase was of the Linz definition. If not, its
reference to
q0, qf and w are all wrong. As a paraphrase of Linz, it's wrong >>>>>>> because
it substitutes ambiguity for clarity. To say that M "transitions >>>>>>> to qf
as a function of w" is pure waffle.
And you don't say what qf is. If you mention it, you should say >>>>>>> why it
matters. But you don't need to mention q0. That's just noise, >>>>>>> as all
TMs start in their start state, and what it's called it
irrelevant to
the paraphrase.
Here's a better paraphrase:
M, given w on its tape, halts with f(w) on the tape, for every
string w
in the domain of f.
It is not a better paraphrase because Linz specifies that the
accept /
reject decision is specified by a state transition.
Gosh. I had no idea you were so confused by Linz's simple definition. >>>>> In short, no it does not. I suspect you have not even read the proper >>>>> definition in a TM. Oh well, it's all details, but you really should >>>>> not try to pick holes in what I say by bringing up details. I am a >>>>> details person.
On 12/17/2021 6:46 PM, Ben Bacarisse wrote:
To say that M "transitions to qf as a function of w" is pure waffle. >>>>>>Because M does transition to qf and
it is common knowledge that f(w) means w is a function of f.
you know that your "correction" is incorrect.
Why lie?
I don't lie. It's waffle. You have taken a precise definition and >>>>> paraphrased it to say almost nothing. All TMs (that halt)
transition to
a halting state "as a function of" their input. You have replaced
everything that matters by vague waffle.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. // Linz says this
Because you have a dogmatic brain incapable of reasoning on its own
you are incapable of directly seeing that Linz's words are not
infallible.
It is not the case that Ĥ has Ĥ as its input so it is not the case
that Ĥ.qx computes the halt status of Ĥ applied to ⟨Ĥ⟩.
H^ has <H^> as its input, which is what H^ applied to <H^> means, thus
Yes this is exactly correct.
it IS the case we hit a contradiction.No because Ĥ.qx reports on the behavior specified by the simulation of
⟨Ĥ⟩ applied to ⟨Ĥ⟩.
It must report on what it derived from that, but if H claims to be a
CORRECT Halt Decider, then that answer MUST match the answer from the defintion of the Problem.
If H is a correct Halt Decider, H(<x>, y) returns Halting if x(y) Halts
and Non-Halting if x(y) never halts. (Not the simulation by H of this,
but the actual computation).
On 12/20/21 11:18 PM, olcott wrote:
On 12/20/2021 9:50 PM, Richard Damon wrote:
On 12/20/21 10:16 PM, olcott wrote:
On 12/20/2021 8:44 PM, Richard Damon wrote:
On 12/20/21 9:19 PM, olcott wrote:Yes this is exactly correct.
On 12/20/2021 8:02 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 6:46 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/17/2021 3:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
A function f with domain D is said to be Turing-computable >>>>>>>>>>>> or just computable if there exists some Turing machine >>>>>>>>>>>> M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* M qf f(w), qf ∈ F
for all w ∈ D (Linz:1990:243)
We all know your cut and paste skills are top notch.
Olcott paraphrase of above machine definition: Machine M >>>>>>>>>>>> begins at
start state q0 on input w and transitions to qf as a
function of input
w.
But that's not a correct paraphrase.
A Turing machine computes a function by starting with the
input to the
function on the tape and halting with the output of the
function on
the tape (Sipser:1997:190).
Within the context of the Sipser and Kozen quotes that you erased >>>>>>>>>> exactly how is my paraphrase of Linz incorrect?
Your paraphrase was of the Linz definition. If not, its
reference to
q0, qf and w are all wrong. As a paraphrase of Linz, it's
wrong because
it substitutes ambiguity for clarity. To say that M
"transitions to qf
as a function of w" is pure waffle.
And you don't say what qf is. If you mention it, you should >>>>>>>>> say why it
matters. But you don't need to mention q0. That's just noise, >>>>>>>>> as all
TMs start in their start state, and what it's called it
irrelevant to
the paraphrase.
Here's a better paraphrase:
M, given w on its tape, halts with f(w) on the tape, for every >>>>>>>>> string w
in the domain of f.
It is not a better paraphrase because Linz specifies that the
accept /
reject decision is specified by a state transition.
Gosh. I had no idea you were so confused by Linz's simple
definition.
In short, no it does not. I suspect you have not even read the >>>>>>> proper
definition in a TM. Oh well, it's all details, but you really
should
not try to pick holes in what I say by bringing up details. I am a >>>>>>> details person.
On 12/17/2021 6:46 PM, Ben Bacarisse wrote:
To say that M "transitions to qf as a function of w" is pure >>>>>>>>> waffle.
Because M does transition to qf and
it is common knowledge that f(w) means w is a function of f.
you know that your "correction" is incorrect.
Why lie?
I don't lie. It's waffle. You have taken a precise definition and >>>>>>> paraphrased it to say almost nothing. All TMs (that halt)
transition to
a halting state "as a function of" their input. You have replaced >>>>>>> everything that matters by vague waffle.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. // Linz says this
Because you have a dogmatic brain incapable of reasoning on its
own you are incapable of directly seeing that Linz's words are not >>>>>> infallible.
It is not the case that Ĥ has Ĥ as its input so it is not the case >>>>>> that Ĥ.qx computes the halt status of Ĥ applied to ⟨Ĥ⟩.
H^ has <H^> as its input, which is what H^ applied to <H^> means, thus >>>>
it IS the case we hit a contradiction.No because Ĥ.qx reports on the behavior specified by the simulation
of ⟨Ĥ⟩ applied to ⟨Ĥ⟩.
It must report on what it derived from that, but if H claims to be a
CORRECT Halt Decider, then that answer MUST match the answer from the
defintion of the Problem.
If H is a correct Halt Decider, H(<x>, y) returns Halting if x(y)
Halts and Non-Halting if x(y) never halts. (Not the simulation by H
of this, but the actual computation).
No you are wrong. H is only allowed to map the behavior of its actual
inputs to an accept / reject state and it can only correctly determine
the behavior of its actual inputs by actually simulating these actual
inputs.
Wrong. Yes, because H needs to be a finite algorithm can only generate
an answer based on processing the actual string it was given as an input.
BUT, the REQUIREMENTS on H are based on the Machine that this input represents.
On 2021-12-21 08:56, olcott wrote:
On 12/21/2021 8:24 AM, Richard Damon wrote:
Wrong. Yes, because H needs to be a finite algorithm can only
generate an answer based on processing the actual string it was given
as an input.
BUT, the REQUIREMENTS on H are based on the Machine that this input
represents.
This is the persistent misconception.
The actual simulation of the actual input is the
only correct basis for any halt status decision.
A "correct basis" for a decision must be one that corresponds to the
function which your decider purports to compute.
Now that you've finally figured out that a Turing Machine is *not* a computable function, do you actually grasp what the halting FUNCTION is
and what it means for something to compute a function?
The halting function is simply a mapping from pairs of TMs/input strings
to either "halts" or "doesn't halt". It is not an algorithm of any sort.
It maps pairs that halt to "halts" and pairs that don't halt to "doesn't halt".
Since H_Hat(H_Hat) halts, it maps (H_Hat, <H_Hat>) to "halts".
Therefore, if your decider actually computes this function, it must
accept the string which represents this pair. That would be <H_Hat>
<H_Hat>.
Linz is wrong on this key point:
No, he is not. His conditions accurately describe the function which the decider purports to compute.
Linz is wrong on this key point:
Linz is wrong on this key point:
<Linz:1990:320>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
</Linz:1990:320>
Once this single point is understood my
refutation will be understood to be correct:
The actual simulation of the actual input is the
only correct basis for any halt status decision.
On 2021-12-21 10:14, olcott wrote:
On 12/21/2021 10:41 AM, André G. Isaak wrote:
On 2021-12-21 08:56, olcott wrote:
On 12/21/2021 8:24 AM, Richard Damon wrote:
Wrong. Yes, because H needs to be a finite algorithm can only
generate an answer based on processing the actual string it was
given as an input.
BUT, the REQUIREMENTS on H are based on the Machine that this input
represents.
This is the persistent misconception.
The actual simulation of the actual input is the
only correct basis for any halt status decision.
A "correct basis" for a decision must be one that corresponds to the
function which your decider purports to compute.
Now that you've finally figured out that a Turing Machine is *not* a
computable function, do you actually grasp what the halting FUNCTION
is and what it means for something to compute a function?
A Turing machine computes a function by starting with the input to the
function on the tape and halting with the output of the function on
the tape (Sipser:1997:190).
A model of computation computes a function by mapping the input to the
function to the output of this function.
The halting function is simply a mapping from pairs of TMs/input
strings to either "halts" or "doesn't halt". It is not an algorithm
of any sort.
No that is totally incorrect. It is never ever the case that any TM
has another TM as its input.
I'm talking about the halting FUNCTION. I'm not talking about a Turing machine. Do you still not grasp the distinction?
It is a mapping of a pair of finite strings to their corresponding
accept reject state on the basis of the behavior specified by the
simulation this pair of finite strings.
The halting FUNCTION doesn't involve simulation of anything. It is
simply a mapping from TM/input pairs to 'halts' or 'doesn't halt.
André
On 2021-12-22 20:59, olcott wrote:
On 12/22/2021 9:42 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
It is not the case that Ĥ has Ĥ as its input
Indeed. Did you ever think it did?
That is what the if Ĥ applied to <Ĥ> means:
Ĥq0 <Ĥ> ⊦* Ĥqx <Ĥ> <Ĥ> ⊦* Ĥqn if Ĥ applied to <Ĥ> does not halt.
You are merely copying the the mistake of Linz verbatim.
That states the *condition* under which Ĥqn is reached.
It makes no claim about Ĥ being an input to Ĥ.
André
olcott <NoOne@NoWhere.com> writes:
On 12/22/2021 9:42 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qnAnd, more importantly, I say that. I don't want to defend Linz's proof
if Ĥ applied to ⟨Ĥ⟩ does not halt. // Linz says this
since we both know it has an error in it (though a minor one). Here's
my proof again:
If a TM, H, existed such that
Hq0 <M> s ⊦* Hqy if M applied to s halts, and
Hq0 <M> s ⊦* Hqn if M applied to s does not halt,
we could construct from it an H' such that
H'q0 <M> s ⊦* oo if M applied to s halts, and
H'q0 <M> s ⊦* H'qn if M applied to s does not halt.
And from that we could construct an Ĥ such that
Ĥq0 <M> ⊦* Ĥqx <M> <M> ⊦* oo if M applied to <M> halts, and >>> Ĥq0 <M> ⊦* Ĥqx <M> <M> ⊦* Ĥqn if M applied to <M> does not halt.
Setting M to Ĥ, so <M> becomes <Ĥ>, we see that the existence of H (as >>> Linz defines it) logically entails that a TM Ĥ that does this
Ĥq0 <Ĥ> ⊦* Ĥqx <Ĥ> <Ĥ> ⊦* oo if Ĥ applied to <Ĥ> halts, and
Ĥq0 <Ĥ> ⊦* Ĥqx <Ĥ> <Ĥ> ⊦* Ĥqn if Ĥ applied to <Ĥ> does not halt.
would also have to exist.
Because you have a dogmatic brain incapable of reasoning on its own
you are incapable of directly seeing that Linz's words are not
infallible.
Curious then, that I have written about, and agreed with you about, the
mistake in Linz's proof. (I much prefer the real proof in Linz -- the
one you have never even read. Don't try, you won't understand it.)
It is not the case that Ĥ has Ĥ as its input
Indeed. Did you ever think it did?
That is what the if Ĥ applied to <Ĥ> means:
No it doesn't. How many years have you been trying to understand this
simple notation? And, more to the point, why bring this up now? Did you think, for the last 15 or so years, the TMs could be given TMs as input?
(These are not rhetorical questions but I don't expect you'll answer
them. You spend a lot of time avoiding direct questions.)
Anyway, now you have shown that you don't know what the notation means
you simply can't make any valid comment on the proof. You need to clear
this up now or everything you write will be bogus.
For a student (one who was interested in learning stuff) I'd give this simpler example: a "parity decider" TM could be defined like this:
P.q0 <n> ⊦* P.gy if n is even, and
P.q0 <n> ⊦* P.gn if n is odd.
See how the condition refers to the number encoded by the string on the initial tape but the TM is not given a number, how could it be? All TMs operate on string representation of things, with the conditions
expressed in terms of the things represented.
The (near) copy of H embedded at Ĥ.qx goes thought the same transitions >>> that H will when given the same input. I.e.
It is an 100% perfectly exact copy
... with qy no longer a final state, and ...
with an infinite loop appended to
the Ĥ.qy path. Figure 12.2 shows that the state qy is not removed.
It's an 100% perfectly exact copy except for the differences, yes. It
hardly matters (since it's the transitions to qy and qn that matter),
but your refusal to admit you are wrong even, about a trivial detail, is
very telling.
olcott <NoOne@NoWhere.com> writes:
On 12/23/2021 9:01 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:I finally have enough of the proper way to say things to say what I
On 12/22/2021 9:42 PM, Ben Bacarisse wrote:No it doesn't. How many years have you been trying to understand this
olcott <NoOne@NoWhere.com> writes:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qnAnd, more importantly, I say that. I don't want to defend Linz's proof >>>>> since we both know it has an error in it (though a minor one). Here's >>>>> my proof again:
if Ĥ applied to ⟨Ĥ⟩ does not halt. // Linz says this
If a TM, H, existed such that
Hq0 <M> s ⊦* Hqy if M applied to s halts, and
Hq0 <M> s ⊦* Hqn if M applied to s does not halt,
we could construct from it an H' such that
H'q0 <M> s ⊦* oo if M applied to s halts, and
H'q0 <M> s ⊦* H'qn if M applied to s does not halt.
And from that we could construct an Ĥ such that
Ĥq0 <M> ⊦* Ĥqx <M> <M> ⊦* oo if M applied to <M> halts, and
Ĥq0 <M> ⊦* Ĥqx <M> <M> ⊦* Ĥqn if M applied to <M> does not halt.
Setting M to Ĥ, so <M> becomes <Ĥ>, we see that the existence of H (as >>>>> Linz defines it) logically entails that a TM Ĥ that does this
Ĥq0 <Ĥ> ⊦* Ĥqx <Ĥ> <Ĥ> ⊦* oo if Ĥ applied to <Ĥ> halts, and
Ĥq0 <Ĥ> ⊦* Ĥqx <Ĥ> <Ĥ> ⊦* Ĥqn if Ĥ applied to <Ĥ> does not halt.
would also have to exist.
Because you have a dogmatic brain incapable of reasoning on its own >>>>>> you are incapable of directly seeing that Linz's words are not
infallible.
Curious then, that I have written about, and agreed with you about, the >>>>> mistake in Linz's proof. (I much prefer the real proof in Linz -- the >>>>> one you have never even read. Don't try, you won't understand it.)
It is not the case that Ĥ has Ĥ as its input
Indeed. Did you ever think it did?
That is what the if Ĥ applied to <Ĥ> means:
simple notation? And, more to the point, why bring this up now? Did you >>> think, for the last 15 or so years, the TMs could be given TMs as input? >>> (These are not rhetorical questions but I don't expect you'll answer
them. You spend a lot of time avoiding direct questions.)
Anyway, now you have shown that you don't know what the notation means
you simply can't make any valid comment on the proof. You need to clear >>> this up now or everything you write will be bogus.
For a student (one who was interested in learning stuff) I'd give this
simpler example: a "parity decider" TM could be defined like this:
P.q0 <n> ⊦* P.gy if n is even, and
P.q0 <n> ⊦* P.gn if n is odd.
See how the condition refers to the number encoded by the string on the
initial tape but the TM is not given a number, how could it be? All TMs >>> operate on string representation of things, with the conditions
expressed in terms of the things represented.
... with qy no longer a final state, and ...The (near) copy of H embedded at Ĥ.qx goes thought the same transitions >>>>> that H will when given the same input. I.e.
It is an 100% perfectly exact copy
with an infinite loop appended toIt's an 100% perfectly exact copy except for the differences, yes. It
the Ĥ.qy path. Figure 12.2 shows that the state qy is not removed.
hardly matters (since it's the transitions to qy and qn that matter),
but your refusal to admit you are wrong even, about a trivial detail, is >>> very telling.
mean clearly unambiguously:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
Linz figure 12.2 shows that Ĥ.qy still exists.
The embedded full copy of H at Ĥ.qx is actually computing
the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn
Yes! Not sure why it took you so long but you did explicitly deny this
for some time.
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy if, and only if, H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and only if, H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
(You are still not stating it entirely property, hence my re-write, but talking about the mapping from the input to some state or other is
relatively clear.)
THIS CHANGES EVERYTHING.
It does indeed! Congratulations! What do you plan to work on now?
On 2021-12-23 15:38, olcott wrote:
On 12/23/2021 4:08 PM, André G. Isaak wrote:
On 2021-12-23 14:59, olcott wrote:
The full copy of the H halt decider at Ĥ.qx
computes the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
This turns out to be entirely different than
determining whether or not Ĥ applied to ⟨Ĥ⟩ halts.
Then your algorithm is broken since the copy of H at Ĥ.qx specifies
the *exact* same decision criteria as H does.
No it freaking well does not.
Ĥ trasitions to its final state on the basis of what Ĥ.qx decides.
And according to the Linz definition of Ĥ, Ĥ.qx transitions to Ĥ.qy iff
Ĥ applied to ⟨Ĥ⟩ halts, and to Ĥ.qn iff Ĥ applied to ⟨Ĥ⟩ does not halt.
If your decider bases its decision on different criteria from these,
then it is *not* an implementation of the Linz Ĥ.
André
On 2021-12-23 17:37, olcott wrote:
On 12/23/2021 5:18 PM, André G. Isaak wrote:
On 2021-12-23 15:38, olcott wrote:
On 12/23/2021 4:08 PM, André G. Isaak wrote:
On 2021-12-23 14:59, olcott wrote:
The full copy of the H halt decider at Ĥ.qx
computes the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
This turns out to be entirely different than
determining whether or not Ĥ applied to ⟨Ĥ⟩ halts.
Then your algorithm is broken since the copy of H at Ĥ.qx specifies >>>>> the *exact* same decision criteria as H does.
No it freaking well does not.
Ĥ trasitions to its final state on the basis of what Ĥ.qx decides.
And according to the Linz definition of Ĥ, Ĥ.qx transitions to Ĥ.qy
iff Ĥ applied to ⟨Ĥ⟩ halts, and to Ĥ.qn iff Ĥ applied to ⟨Ĥ⟩ does not
halt.
How many times do I have to tell you that this is incorrect because it
is not the same thing as the mapping that the full copy of H computes
from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn ???
It may be the case that YOUR algorithm computes something different, but
then your algorithm fails to meet the definition for Linz's Ĥ.
On 2021-12-24 19:49, olcott wrote:
Because Ben's augmented notation would apply at every nested
simulation level it may be a significant increase in clarity.
H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
Why are you happy with this, despite the fact that UTM(wM, w) is *not*
an input to H, but you object to the following
On 12/25/21 3:41 PM, olcott wrote:
On 12/25/2021 2:07 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/24/2021 8:50 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 12/24/2021 3:29 PM, Ben Bacarisse wrote:And, much to my surprise, you are clear that you do indeed claim the >>>>> second of these to be true!
olcott <NoOne@NoWhere.com> writes:
On 12/23/2021 7:18 PM, Ben Bacarisse wrote:
I will stick to symbols. So you think that one or both of
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy but H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊬* H.qy
or
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn but H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊬* H.qn
is possible?
<cut>If so, you are wrong. If you don't, you agree with this:
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy if, and only if, H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢*
H.qy
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and only if, H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢*
H.qn
Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
corresponds to
H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy
The copy of H at Ĥ.qx... which is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ...
correctly decides that its input never halts.Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and only if, H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts. >>>>> I.e.
⊢* H.qn
but
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
which is obviously absurd. It's logically absurd, but even if you
prevent logical deduction by removing the annotations (as you
repeatedly
do), it's still patently absurd to claim that the same state
transition
function and input results in different state transitions.
At least you are not trying to hide anything. You explicitly claim an >>>>> absurdity. No one can take this seriously.
It is not absurd at all.
If you can't see it, you are doomed to keep writing absurd things.
One reason you can't see it is that you think waffle carries the same
weight as logic. If logic determines that some x must be less than
three and greater than five, you will argue that x can see what it's
being compared to and make itself very small or very big as needed.
H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
As soon as H(x,y) knows that UTM(x,y) never halts it is always correct
for H to report that its input never halts. THERE ARE NO EXCEPTIONS
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
NO!!!!
olcott <NoOne@NoWhere.com> writes:
On 12/26/2021 7:37 PM, Ben Bacarisse wrote:
The second point is so significant that you can't say /anything/ about
TMs until you accept that you are wrong. No TM can be built around a
copy of another in any reliable way, because in PO-land identical copies >>> don't behave identically.
All statements you make about TMs are simply junk until you accept that
a TM's behaviour is determined slowly by the input and the state
transition function.
When we arrange one copy of a computation to change its behavior on
the basis of another copy of this computation thus be dependent on the
second copy whereas this second copy is not dependent on any other
computation then we can correctly expect different results.
If it's a copy it behaves identically. A TM this does not behave like
the one it is based on is not a copy. To arrange for a copy of a TM to behave differently, with the same tape, is just Orwellian double speak.
You just need to put your hand up to the mistake and move on.
We know your "two computations" ruse. It's been 100% clear since you
claimed that Halts(Confound_Halts, Confound_Halts) == false is correct because of what Halts would do with line 15 commented out! You moved on
from that, making Halts sensitive to its execution environment, but you
can't pull that trick with TMs. The only execution environment a TM has
is the current state and the tape contents.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 427 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:31:00 |
| Calls: | 9,027 |
| Calls today: | 10 |
| Files: | 13,384 |
| Messages: | 6,008,640 |