olcott <polcott2@gmail.com> writes:
On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 11:07 AM, Ben Bacarisse wrote:I can't parse that sentence but it contains no hint that you have looked >>> at Linz's proof yet.
olcott <NoOne@NoWhere.com> writes:
Linz confuses himself my making the TM descriptions less than a clear >>>>>> as possible.
Have you looked at Linz's actual proof yet? It's theorem 12.2, a page >>>>> further on from the one you seem to be obsessed by.
Like I said my only reply to you will be to keep repeating the key
points that you failed to address until you address them completely.
Do you understand that a decider computes the mapping ONLY from its
inputs to an accept or reject state and does not compute any other
mapping?
So no, you have not looked at Linz's proof yet.
By the way, I am not going to answer patronising questions. But by all
means ask me to tell you what a decider is, provided you are prepared to
use that definition (and terminology) in future exchanges.
On 3/2/22 6:35 PM, olcott wrote:
On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 11:07 AM, Ben Bacarisse wrote:looked
olcott <NoOne@NoWhere.com> writes:
Linz confuses himself my making the TM descriptions less than a >>>>>>>> clear
as possible.
Have you looked at Linz's actual proof yet? It's theorem 12.2, a >>>>>>> page
further on from the one you seem to be obsessed by.
Like I said my only reply to you will be to keep repeating the key >>>>>> points that you failed to address until you address them completely. >>>>> I can't parse that sentence but it contains no hint that you have
at Linz's proof yet.
Do you understand that a decider computes the mapping ONLY from its
inputs to an accept or reject state and does not compute any other
mapping?
So no, you have not looked at Linz's proof yet.
By the way, I am not going to answer patronising questions. But by all >>> means ask me to tell you what a decider is, provided you are prepared to >>> use that definition (and terminology) in future exchanges.
You have proven that you do not understand that deciders ONLY compute
the mapping from their inputs to an accept or reject state by
perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ has anything >> to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The embedded copy of H at Ĥ.qx does not compute the halt status of
itself or the computation that contains it: Ĥ ⟨Ĥ⟩.
Then it isn't a Halt Decider. Thanks for making that Clear.
FAIL,
On 3/2/22 8:09 PM, olcott wrote:Because it is not an input to the decider it is out-of-scope for the
On 3/2/2022 6:56 PM, Richard Damon wrote:
On 3/2/22 7:29 PM, olcott wrote:
On 3/2/2022 6:16 PM, Richard Damon wrote:
On 3/2/22 6:35 PM, olcott wrote:
On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 11:07 AM, Ben Bacarisse wrote:I can't parse that sentence but it contains no hint that you >>>>>>>>> have looked
olcott <NoOne@NoWhere.com> writes:
Linz confuses himself my making the TM descriptions less >>>>>>>>>>>> than a clear
as possible.
Have you looked at Linz's actual proof yet? It's theorem >>>>>>>>>>> 12.2, a page
further on from the one you seem to be obsessed by.
Like I said my only reply to you will be to keep repeating the >>>>>>>>>> key
points that you failed to address until you address them
completely.
at Linz's proof yet.
Do you understand that a decider computes the mapping ONLY from its >>>>>>>> inputs to an accept or reject state and does not compute any other >>>>>>>> mapping?
So no, you have not looked at Linz's proof yet.
By the way, I am not going to answer patronising questions. But >>>>>>> by all
means ask me to tell you what a decider is, provided you are
prepared to
use that definition (and terminology) in future exchanges.
You have proven that you do not understand that deciders ONLY
compute the mapping from their inputs to an accept or reject state >>>>>> by perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ has >>>>>> anything to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The embedded copy of H at Ĥ.qx does not compute the halt status of >>>>>> itself or the computation that contains it: Ĥ ⟨Ĥ⟩.
Then it isn't a Halt Decider. Thanks for making that Clear.
FAIL,
You too are not aware that deciders ONLY compute the mapping from
their inputs to an accept or reject state. You and Ben still think
that deciders must compute mappings from non-inputs.
Right, they compute the CORRECT mapping of their inputs, and the
CORRECT mapping for a Halt Decider is H applied <M> w depends on the
behavior of M applied to w, so H applied to <H^> <H^> IS responsible
for the behavior of H^ applied to <H^> BY DEFINITION.
So, your claim that this isn't what your H does, just PROVES that
your H is NOT computing the Halting Function, and thus is NOT a Halt
Decider.
Thank you for admitting that, or are you just a pathological liar?
The embedded copy of H at Ĥ.qx does not compute the halt status of
itself or the computation that contains it: Ĥ ⟨Ĥ⟩.
Ĥ ⟨Ĥ⟩ is not an input to embedded_H NITWIT
Ĥ ⟨Ĥ⟩ is not an input to embedded_H NITWIT
Ĥ ⟨Ĥ⟩ is not an input to embedded_H NITWIT
Ĥ ⟨Ĥ⟩ is not an input to embedded_H NITWIT
But it IS the thing that determine the correct answer for embedded_H if
it is a Halt Decider, so it must not be.
On 3/2/22 9:36 PM, olcott wrote:
On 3/2/2022 8:33 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 11:07 AM, Ben Bacarisse wrote:I can't parse that sentence but it contains no hint that you have >>>>>>> looked
olcott <NoOne@NoWhere.com> writes:
Linz confuses himself my making the TM descriptions less than >>>>>>>>>> a clear
as possible.
Have you looked at Linz's actual proof yet? It's theorem 12.2, >>>>>>>>> a page
further on from the one you seem to be obsessed by.
Like I said my only reply to you will be to keep repeating the key >>>>>>>> points that you failed to address until you address them
completely.
at Linz's proof yet.
Do you understand that a decider computes the mapping ONLY from its >>>>>> inputs to an accept or reject state and does not compute any other >>>>>> mapping?
So no, you have not looked at Linz's proof yet.
By the way, I am not going to answer patronising questions. But by >>>>> all
means ask me to tell you what a decider is, provided you are
prepared to
use that definition (and terminology) in future exchanges.
You have proven that you do not understand that deciders ONLY compute
the mapping from their inputs to an accept or reject state by
perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ has anything
to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
If you are prepared to learn with an open mind, I can take you through
some exercises that will explain to you why this objection is
groundless. Of course, you can continue to spout nonsense -- that's no >>> problem for me -- but you claim to want to talk about this problem, and
that involves understanding which strings to accept and which reject.
You simply ignored my proof of my point proving that you are dishonest.
Nope, you ignore the proofs that you are wrong, AND a Liar.
On 3/2/22 10:21 PM, olcott wrote:
On 3/2/2022 8:43 PM, Richard Damon wrote:
On 3/2/22 9:36 PM, olcott wrote:
On 3/2/2022 8:33 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 5:16 PM, Ben Bacarisse wrote:If you are prepared to learn with an open mind, I can take you through >>>>> some exercises that will explain to you why this objection is
olcott <polcott2@gmail.com> writes:
On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 11:07 AM, Ben Bacarisse wrote:I can't parse that sentence but it contains no hint that you >>>>>>>>> have looked
olcott <NoOne@NoWhere.com> writes:
Linz confuses himself my making the TM descriptions less >>>>>>>>>>>> than a clear
as possible.
Have you looked at Linz's actual proof yet? It's theorem >>>>>>>>>>> 12.2, a page
further on from the one you seem to be obsessed by.
Like I said my only reply to you will be to keep repeating the >>>>>>>>>> key
points that you failed to address until you address them
completely.
at Linz's proof yet.
Do you understand that a decider computes the mapping ONLY from its >>>>>>>> inputs to an accept or reject state and does not compute any other >>>>>>>> mapping?
So no, you have not looked at Linz's proof yet.
By the way, I am not going to answer patronising questions. But >>>>>>> by all
means ask me to tell you what a decider is, provided you are
prepared to
use that definition (and terminology) in future exchanges.
You have proven that you do not understand that deciders ONLY compute >>>>>> the mapping from their inputs to an accept or reject state by
perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ has >>>>>> anything
to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. >>>>>
groundless. Of course, you can continue to spout nonsense --
that's no
problem for me -- but you claim to want to talk about this problem,
and
that involves understanding which strings to accept and which reject. >>>>>
You simply ignored my proof of my point proving that you are dishonest. >>>>
Nope, you ignore the proofs that you are wrong, AND a Liar.
Most often your rebuttals are only confused gibberish.
Your key mistake is not having the slightest idea of how simulating
halt deciders work even though I have explained it many hundreds of
times.
You keep thinking that if a simulating halt decider must abort its
simulation to report that its input specifies a non-halting sequence
of configurations that this makes this input halt and thus the
reported non-halting wrong.
_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]
The above specifies an infinite loop even when its simulation has been
aborted to report "infinite loop".
It isn't the decider aborting that makes H^ Halting, it is H going to
H.Qn that makes H^ non-halting (since H^ x will always go to H^.Qn and
halt if H x x goes to H.Qn)
H is perfectly allowed to abort its simulation and do something else,
either loop forever or go to H.Qy, and H^ will stay non-halting, its
just H didn't give the right answer.
You are just confused about how cause and effect work.
FAIL.
olcott <polcott2@gmail.com> writes:
On 3/3/2022 5:56 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
This is not about rehashing old points this is about evaluating newThe eternal refrain of the Usenet crank: talk to me about this new
points.
nonsense; forget I ever said that old nonsense.
My posts will be about whatever I want them to be about. Of course you
will ignore all your old mistakes -- you ignored them when they were new >>> mistakes!
I have proven that your rebuttals from six months ago are incorrect on
the basis of a better analysis. It is OK if you want to chicken out,
you are not my target audience.
By my reckoning, you first claimed to have refuted every proof[1] of
this simple theorem over 17 years ago. 17 years. How long can on paper
take to finish?
You are never going to get a paper on this topic published (published --
not self-published). Whether you like it or not I am your target
audience, along with anyone else here who will tell you that you are wrong[2]. That's why you are still replying to me despite having just
said that you won't until I "fully address" whatever the latest junk
idea was.
Every single attempt you have made to undermine this simple theorem has
been wrong. After almost 18 years of misunderstandings, daft ideas,
deluded claims, doubling down and doubling back, there has not been a
single idea that would get past a journal editor's joke pile. This
includes the latest ridiculous misconception which I genuinely thought
you might be able to overcome with a little coaching. But, no, you
don't want to learn anything (though the offer remains open).
With my human hat on, I really wish you would do something else. There
is so much more to enjoy in the world. I know we share a love of dogs.
I am learning to become a dog training instructor, and every week I get
to work with dozens of owners and their amazing dogs. I love it. It's
quite a change of style from academic computer science. Please consider
some other use of your time.
[1] Have you even read Linz's actual halting theorem proof yet? The
proper one?
[2] It's a curios fact that the one things that really annoys a Usenet
crank is being agreed with. You'd think that all the Cantor deniers and Gödel refuters would get together a push a magnum opus (something they clearly can't do that on their own), but no. To paraphrase Tolstoy, all valid propositions are alike, but all crank ideas are wrong in their own particular way.
On 3/3/22 10:05 PM, olcott wrote:
On 3/3/2022 8:39 PM, Richard Damon wrote:
On 3/3/22 9:05 PM, olcott wrote:
On 3/3/2022 7:14 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/3/2022 5:56 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
This is not about rehashing old points this is about evaluating new >>>>>>>> points.The eternal refrain of the Usenet crank: talk to me about this new >>>>>>> nonsense; forget I ever said that old nonsense.
My posts will be about whatever I want them to be about. Of
course you
will ignore all your old mistakes -- you ignored them when they
were new
mistakes!
I have proven that your rebuttals from six months ago are
incorrect on
the basis of a better analysis. It is OK if you want to chicken out, >>>>>> you are not my target audience.
By my reckoning, you first claimed to have refuted every proof[1] of >>>>> this simple theorem over 17 years ago. 17 years. How long can on >>>>> paper
take to finish?
I have to make my proof so clearly correct that it is fully
understood before it is rejected out-of-hand on the basis of its
subject matter.
I still need to learn more about computable functions. None of the
theory of computation textbooks go into the same depth that others
here refer to. I was not sure that a RASP computable function could
know its own machine address until André's explanation.
So you ADMIT you don't know the basic meaning of things in the
Theory, but you have made claims based on things that you claim are
obvious by 'The meaning of the words' that include these terms.
I did not know that a RASP function can know its own address and still
be construed as a computation in computer science.
The problem you are going to run into is that RASP machines don't have 'input' as generally constructed. This makes it harder to design a RASP machine that takes as an input the description of another arbitrary computation. (This is the same problem you 'H' program has).
I have proven that I have refuted the halting problem proofs
categorically. I only need to perfect my use of terminology.
Not 'Perfect', first you need to learn the basics of the terminology.
THIS IS THE KEY ESSENCE OF MY PROOF
Infinitely Recursive input on HP Proofs
comp.theory Mar 11, 2017, 3:13:03 PM peteolcott
https://groups.google.com/g/comp.theory/c/NcFS02hKs1U/m/PlBF-1LRBAAJ
I actually inadvertently came up with it in this paper:
Self Modifying Turing Machine (SMTM) Solution to the Halting Problem
(concrete example) August 2016
Which shows you don't understand how Turing Machines work. Turing
Machine have no way to 'access' there code to make the changes.
I pointed to this paper as the origin of the key element of my current
proof.
Also, they don't NEED to change there code, they just need a
'state-bit' to decide on each of the options they might be able to
reprogram themselves with.
Your description (from what I remember) actually needed an 'external
agent' to actually make the sort of changes you wanted to do, and
thus, you actually need to fold that external agent into the Turing
Machine to make it back into an actual computation, and then it fails
to have that 'magical' property of not being able to be 'outwitted'
by a machine using it.
FAIL.
https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example
No one has actually pointing out any error in the essence of what I
have said:
Simple English version of Olcott's Halt status criterion measure:
Every simulating halt decider that must abort the simulation of its
input to prevent its infinite simulation correctly transitions to
its reject state.
Which is the WRONG definition.
It is an unconventional new definition that maps to the original
definition thus is provably equivalent.
Nope, not equivalent. If it WAS equivelent it would give the same answer
for H^ applied to <H^>, which it doesn't.
Shows you don't even know the meaning of 'Equivalent'
On 3/3/22 10:39 PM, olcott wrote:
On 3/3/2022 9:22 PM, Richard Damon wrote:
On 3/3/22 10:05 PM, olcott wrote:
On 3/3/2022 8:39 PM, Richard Damon wrote:
On 3/3/22 9:05 PM, olcott wrote:
On 3/3/2022 7:14 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/3/2022 5:56 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
This is not about rehashing old points this is aboutThe eternal refrain of the Usenet crank: talk to me about this new >>>>>>>>> nonsense; forget I ever said that old nonsense.
evaluating new
points.
My posts will be about whatever I want them to be about. Of >>>>>>>>> course you
will ignore all your old mistakes -- you ignored them when they >>>>>>>>> were new
mistakes!
I have proven that your rebuttals from six months ago are
incorrect on
the basis of a better analysis. It is OK if you want to chicken >>>>>>>> out,
you are not my target audience.
By my reckoning, you first claimed to have refuted every proof[1] of >>>>>>> this simple theorem over 17 years ago. 17 years. How long can >>>>>>> on paper
take to finish?
I have to make my proof so clearly correct that it is fully
understood before it is rejected out-of-hand on the basis of its
subject matter.
I still need to learn more about computable functions. None of the >>>>>> theory of computation textbooks go into the same depth that others >>>>>> here refer to. I was not sure that a RASP computable function
could know its own machine address until André's explanation.
So you ADMIT you don't know the basic meaning of things in the
Theory, but you have made claims based on things that you claim are
obvious by 'The meaning of the words' that include these terms.
I did not know that a RASP function can know its own address and
still be construed as a computation in computer science.
The problem you are going to run into is that RASP machines don't
have 'input' as generally constructed. This makes it harder to design
a RASP machine that takes as an input the description of another
arbitrary computation. (This is the same problem you 'H' program has).
I have proven that I have refuted the halting problem proofs
categorically. I only need to perfect my use of terminology.
Not 'Perfect', first you need to learn the basics of the terminology.
I know that all deciders compute the mapping from their input finite
strings to an accept or reject state. You and Ben prove that you do
not understand that halt deciders are deciders.
I have never said anything against H being a decider, just that the
function it computes is not the halting function.
You keep on quoting some made up rule that somehow the behavior of H^
applied to <H^> can't be the basis of the correct answer for H applied
to <H^> <H^> since it isn't what the 'input' is.
On 2022-03-03 14:58:15 +0000, olcott said:
On 3/3/2022 4:34 AM, Mikko wrote:
On 2022-03-03 03:13:35 +0000, olcott said:
We make it even simpler a decider is required to compute the mapping
from its finite string input to an accept or reject state.
Irrelevant, as Linz' Definition 12.1 does not use the word "decider" and >>> does not require that the solution to the halting problem be a decider.
Mikko
All halt deciders are deciders.
The definition 12.1 does not say so.
Mikko
olcott <NoOne@NoWhere.com> writes:
On 3/3/2022 7:14 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/3/2022 5:56 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
This is not about rehashing old points this is about evaluating new >>>>>> points.The eternal refrain of the Usenet crank: talk to me about this new
nonsense; forget I ever said that old nonsense.
My posts will be about whatever I want them to be about. Of course you >>>>> will ignore all your old mistakes -- you ignored them when they were new >>>>> mistakes!
I have proven that your rebuttals from six months ago are incorrect on >>>> the basis of a better analysis. It is OK if you want to chicken out,
you are not my target audience.
By my reckoning, you first claimed to have refuted every proof[1] of
this simple theorem over 17 years ago. 17 years. How long can on paper >>> take to finish?
I have to make my proof so clearly correct that it is fully understood
before it is rejected out-of-hand on the basis of its subject matter.
Your recent work will be rejected out of hand if you are clear, because
it will be clear that you are not talking about the halting problem. If
you find a way of describing it that is so convoluted that it's not immediately clear, it will be rejected because it's too vague.
It's possible that, as below, you accidentally do end up talking about
the halting problem. Then your work will be rejected because that
question is settled. In this case, to get out of the editor's joke
pile, you would have to show a flaw in every proof, and you have not
even read Linz's proof (the real one, not the one presented, rather
sloppily in my opinion, for historical interest) let along all the
others.
Attacking proofs raises an even bigger problem for you: you don't know
what a proof is. You still think that if {A} ⊦ X, then {A,~A} ⊬ X so there is really nothing you can do in terms of the existing proofs that
won't be "joke pile" ready from the get-go.
I still need to learn more about computable functions. None of the
theory of computation textbooks go into the same depth that others
here refer to.
Have you actually read a book on this topic? There's no sign that you
have. You didn't even know what a function was a few months ago.
No one has actually pointing out any error in the essence of what I
have said:
At least three people have done exactly that. Many times. And quite a
few more than three over the 17 years you've been trying to say
something original on this topic. What you mean is that you ignore or
don't understand the errors being pointed out to you.
Simple English version of Olcott's Halt status criterion measure:
Every simulating halt decider that must abort the simulation of its
input to prevent its infinite simulation correctly transitions to its
reject state.
Let me point out the error yet again: this is not the halting problem.
Somewhat formalized version of Olcott's Halt status criterion measure:
Let ⟨M⟩ describe a Turing machine M = (Q, Σ, Γ, δ, q₀, □, F), and let
w be any element of Σ⁺, A solution of the halting problem is a Turing
machine H, which for any ⟨M⟩ and w, performs the computation (Linz
1990:317)
Writing "Linz 1990:317" make it look like you are quoting Linz, but this
is not a direct quote.
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
"UTM(⟨M⟩, w) reaches the final state of M" if, and only if, "M halts on input w" so your conditions are correct, and the same as Linz's.
This is the halting problem, pointlessly reworded in terms of a UTM so
you should be able to write out the rest of the proof using the
Of course, your rewording is technically wrong because you don't do
details, but unless you want to be taken 100% literally at your word, I
don't think they stop you being understood.
But you don't want to be understood to be talking about Linz's simple conditions -- you want to talk about the problem with the "revised
criteria" that is not the HP. That puts you in a bind. Talk about the
HP and you have to find flaws in proofs you can't understand. Talk
about your other problem, and no one will care.
olcott <NoOne@NoWhere.com> writes:
I know that all deciders compute the mapping from their input finite
strings to an accept or reject state. You and Ben prove that you do
not understand that halt deciders are deciders.
Lying about technical matters is one thing[1], but lying about people is
not on. It's despicable and you should stop doing it.
[1] To pick a couple out of many:
"I provide the exact ⊢* wildcard states after the Linz H.q0 and after
Ĥ.qx ... showing exactly how the actual Linz H would correctly decide
the actual Linz (Ĥ, Ĥ)."
"I now have an actual H that decides actual halting for an actual (Ĥ,
Ĥ) input pair. I have to write the UTM to execute this code, that
should not take very long. The key thing is the H and Ĥ are 100%
fully encoded as actual Turing machines."
olcott <NoOne@NoWhere.com> writes:It seems that all you have is one dishonest dodge or another. I have not
On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
I know that all deciders compute the mapping from their input finiteLying about technical matters is one thing[1], but lying about people is >>> not on. It's despicable and you should stop doing it.
strings to an accept or reject state. You and Ben prove that you do
not understand that halt deciders are deciders.
When you would actually directly address the point at hand you have no
rebuttal because it is correct.
What are you waffling about now? Of course a halt decider (were such a
thing to exist) would be a decider. Your lie is that neither I nor
Richard have ever said what claim. Continuing to lie about what people
claim is despicable. You've done it before. You will probably keep
doing it.
THIS IS THE POINT AT HAND
By which you mean this the current distraction from 17 years of
uncorrected mistakes.
It is the case that all deciders ONLY compute the mapping from their
input finite strings to an accept or reject state thus everything that
is not an input finite sting is out-of-scope for the decider.
Apart form the bad wording, no one has ever objected to that.
This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
accept or reject state and is not allowed to report on the behavior of
the computation that contains itself Ĥ ⟨Ĥ⟩.
Nonsense. First off, this is a silly use of language -- a TM is not "allowed" or "not allowed" to do anything. A TM+input entails a
sequence of configurations determined solely by the state transition
function and the input. They have do not need permission for anything,
and permission can not be withdrawn about anything.
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
configurations up to qn or qy. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
H accepts ⟨Ĥ⟩ ⟨Ĥ⟩. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.
olcott <NoOne@NoWhere.com> writes:
On 3/4/2022 11:36 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/4/2022 9:29 AM, Ben Bacarisse wrote:What are you waffling about now? Of course a halt decider (were such a
olcott <NoOne@NoWhere.com> writes:
I know that all deciders compute the mapping from their input finite >>>>>> strings to an accept or reject state. You and Ben prove that you do >>>>>> not understand that halt deciders are deciders.Lying about technical matters is one thing[1], but lying about people is >>>>> not on. It's despicable and you should stop doing it.
When you would actually directly address the point at hand you have no >>>> rebuttal because it is correct.
thing to exist) would be a decider. Your lie is that neither I nor
Richard have ever said what claim. Continuing to lie about what people
claim is despicable. You've done it before. You will probably keep
doing it.
THIS IS THE POINT AT HANDBy which you mean this the current distraction from 17 years of
uncorrected mistakes.
It is the case that all deciders ONLY compute the mapping from theirApart form the bad wording, no one has ever objected to that.
input finite strings to an accept or reject state thus everything that >>>> is not an input finite sting is out-of-scope for the decider.
This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
accept or reject state and is not allowed to report on the behavior of >>>> the computation that contains itself Ĥ ⟨Ĥ⟩.
Nonsense. First off, this is a silly use of language -- a TM is not
"allowed" or "not allowed" to do anything. A TM+input entails a
sequence of configurations determined solely by the state transition
function and the input. They have do not need permission for anything,
and permission can not be withdrawn about anything.
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
configurations up to qn or qy. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
H accepts ⟨Ĥ⟩ ⟨Ĥ⟩. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.
It seems that all you have is one dishonest dodge or another. I have
not been speaking about H for many months so when you bring it up now
it is a direct dodge of the point at hand.
Of course you are not speaking about H. You are wrong about H so you
must try to not talk about it anymore. Ironically it's you that want me
to dodge this issue: if I can't talk about H, you condemn me to do
nothing but dodge the key point -- that H is wrong.
When embedded_H computes the mapping from its input finite string pair
⟨Ĥ⟩ ⟨Ĥ⟩ inputs to an accept or reject state it does this on the basis
of the behavior specified by this finite string pair: ⟨Ĥ⟩ ⟨Ĥ⟩
Sign. I wish you could get the details right. It would allow a
discussion of the big mistakes. embedded_H has no accepting state.
Anyway, I can't tell you why you are wrong because I must not talk about
H. Great -- that simplifies my replies a lot.
and not on the basis of the behavior of the computation that contains
itself: Ĥ ⟨Ĥ⟩.
Fortunately for you, you have banned me from telling you why this is
wrong!
Your failure to understand this proves that you do not sufficiently
understand how deciders work.
I know why you are wrong, but if I told you I would, apparently, be
dodging something! Enjoy your ignorance. If it gets tedious, the offer
to explain remains open...
olcott <NoOne@NoWhere.com> writes:
When a sequence of configurations would never reach their final state
in any finite number of steps of pure simulation then this sequence of
configurations specify non-halting behavior.
This is the halting problem. It is better expressed in the simpler
terms given in texts like Linz. I don't like the wording, just gives
the gist.
The criterion measure shown below defines the set of configurations
that never reach their final state.
Simple English version of Olcott's Halt status criterion measure:
Every simulating halt decider that must abort the simulation of its
input to prevent its infinite simulation correctly transitions to its
reject state.
This is not the halting problem. Its even more badly written than the
first (for example, it's circular, and uses undefined metaphors like
"abort") but it conveys enough for readers to know that it's not the
correct criterion for the halting problem. It's this "Halt status
criterion measure" (pompous or what?) that permits your decider to
reject a string that represents a halting computation.
You need to pick what H is defined to do -- decide halting (as in Linz),
or to decide PO-almost-but-not-really halting (which no one but you
cares about). But it's clear from the above that are trying to
equivocate -- its the same as halting, honest! -- just re-worded so it
isn't.
olcott <NoOne@NoWhere.com> writes:
On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
When a sequence of configurations would never reach their final state
in any finite number of steps of pure simulation then this sequence of >>>> configurations specify non-halting behavior.
This is the halting problem. It is better expressed in the simpler
terms given in texts like Linz. I don't like the wording, just gives
the gist.
OK good so far.
The criterion measure shown below defines the set of configurations
that never reach their final state.
Simple English version of Olcott's Halt status criterion measure:
Every simulating halt decider that must abort the simulation of its
input to prevent its infinite simulation correctly transitions to its
reject state.
This is not the halting problem. Its even more badly written than the
first (for example, it's circular, and uses undefined metaphors like
"abort") but it conveys enough for readers to know that it's not the
correct criterion for the halting problem. It's this "Halt status
criterion measure" (pompous or what?) that permits your decider to
reject a string that represents a halting computation.
When a simulating halt decider correctly determines its correctly
simulated input would never reach its final state in any finite number
of steps of pure simulation then this simulating halt decider has
correctly determined that this input specifies non-halting behavior.
There is no such thing as a simulating halt decider because there are no
halt deciders at all.
But we can find out what you are saying about
these things asking if a TM, any TM, can do what you say:
When a TM (any TM) correctly determines its correctly simulated input
would never reach its final state in any finite number of steps of pure simulation then this TM has correctly determined that this input
specifies non-halting behavior.
And re-worded again using tighter language and without all the filler
words:
When a TM determines that a simulation of its input would not halt it
can correctly report that the input represents a non-halting
computation.
And even more simply (and obviously):
When a TM determines that its input represents a non-halting computation
it can correct report that the input represents a non-halting
computation.
Kind of pointless thing to say, isn't it? Such TMs are ten-a-penny.
The irony is that you limited your claim (a safe and reasonable claim as
I hope you can see) to the very class of TMs that /can't/ do what you
say because there are none!
olcott <NoOne@NoWhere.com> writes:
On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/4/2022 5:37 PM, Ben Bacarisse wrote:There is no such thing as a simulating halt decider because there are no >>> halt deciders at all.
olcott <NoOne@NoWhere.com> writes:
When a sequence of configurations would never reach their final state >>>>>> in any finite number of steps of pure simulation then this sequence of >>>>>> configurations specify non-halting behavior.
This is the halting problem. It is better expressed in the simpler
terms given in texts like Linz. I don't like the wording, just gives >>>>> the gist.
OK good so far.
The criterion measure shown below defines the set of configurations >>>>>> that never reach their final state.
Simple English version of Olcott's Halt status criterion measure:
Every simulating halt decider that must abort the simulation of its >>>>>> input to prevent its infinite simulation correctly transitions to its >>>>>> reject state.
This is not the halting problem. Its even more badly written than the >>>>> first (for example, it's circular, and uses undefined metaphors like >>>>> "abort") but it conveys enough for readers to know that it's not the >>>>> correct criterion for the halting problem. It's this "Halt status
criterion measure" (pompous or what?) that permits your decider to
reject a string that represents a halting computation.
When a simulating halt decider correctly determines its correctly
simulated input would never reach its final state in any finite number >>>> of steps of pure simulation then this simulating halt decider has
correctly determined that this input specifies non-halting behavior.
Then call it a halt determiner.
What they are called is not really very important. What they do is
crucial.
But we can find out what you are saying about
these things asking if a TM, any TM, can do what you say:
When a TM (any TM) correctly determines its correctly simulated input
would never reach its final state in any finite number of steps of pure
simulation then this TM has correctly determined that this input
specifies non-halting behavior.
And re-worded again using tighter language and without all the filler
words:
When a TM determines that a simulation of its input would not halt it
can correctly report that the input represents a non-halting
computation.
Not precise enough. It must be a simulation performed by the
simulating halt determiner.
Ah, then you need to define what that is. If it's different to a
simulator in any significant way then your statements is not about the halting problem and can be ignored.
When a TM determines that [its correct pure] simulation of its input
would not halt it can correctly report that the input represents a
non-halting computation.
This is either the same as my re-write (if you remove the [...] part or replace "its" with "a") or it is an attempt to obscure the that fact
that the "determiner" can ignore some halting computations because "it" halted them. I am sure it the latter this as been you ruse for ages.
Anyway, you should either write the correct condition as found in every textbook you've never read, or just come clean that you are not talking
about the halting problem.
Your definition will be to confusing for people that are not computer
scientists because they will believe that when the simulating halt
determiner aborts its simulation that this causes the input to halt,
thus the halt determiner is contradicting itself.
My definition did not use undefined terms like "simulating halt
determiner" or "abort". And mine had no absurd vague "its" in it.
And even more simply (and obviously):
When a TM determines that its input represents a non-halting computation >>> it can correct report that the input represents a non-halting
computation.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Of course you miss of the key conditions because you have not yet found
a way to write the that fools anyone:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.
Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
⟨Ĥ⟩.qn ?
Who knows? You have not defined what ⟨Ĥ⟩.qn means. In Linz, embedded_H is the same as H (with a few tweaks) and can't correctly transition to
either Ĥ.qn or Ĥ.qy.
Your embedded_H is a mystery because it's not as in Linz.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
OK. You are permitted to say that that is what you Ĥ does. Why should anyone care?
Why should anyone care?
olcott <NoOne@NoWhere.com> writes:
On 3/6/2022 11:36 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/5/2022 2:38 PM, Ben Bacarisse wrote:What they are called is not really very important. What they do is
olcott <NoOne@NoWhere.com> writes:
On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
When a sequence of configurations would never reach their final state >>>>>>>> in any finite number of steps of pure simulation then this sequence of >>>>>>>> configurations specify non-halting behavior.
This is the halting problem. It is better expressed in the simpler >>>>>>> terms given in texts like Linz. I don't like the wording, just gives >>>>>>> the gist.
OK good so far.
The criterion measure shown below defines the set of configurations >>>>>>>> that never reach their final state.
Simple English version of Olcott's Halt status criterion measure: >>>>>>>> Every simulating halt decider that must abort the simulation of its >>>>>>>> input to prevent its infinite simulation correctly transitions to its >>>>>>>> reject state.
This is not the halting problem. Its even more badly written than the >>>>>>> first (for example, it's circular, and uses undefined metaphors like >>>>>>> "abort") but it conveys enough for readers to know that it's not the >>>>>>> correct criterion for the halting problem. It's this "Halt status >>>>>>> criterion measure" (pompous or what?) that permits your decider to >>>>>>> reject a string that represents a halting computation.
When a simulating halt decider correctly determines its correctly
simulated input would never reach its final state in any finite number >>>>>> of steps of pure simulation then this simulating halt decider has
correctly determined that this input specifies non-halting behavior. >>>>> There is no such thing as a simulating halt decider because there are no >>>>> halt deciders at all.
Then call it a halt determiner.
crucial.
But we can find out what you are saying about
these things asking if a TM, any TM, can do what you say:
When a TM (any TM) correctly determines its correctly simulated input >>>>> would never reach its final state in any finite number of steps of pure >>>>> simulation then this TM has correctly determined that this input
specifies non-halting behavior.
And re-worded again using tighter language and without all the filler >>>>> words:
When a TM determines that a simulation of its input would not halt it >>>>> can correctly report that the input represents a non-halting
computation.
Not precise enough. It must be a simulation performed by the
simulating halt determiner.
Ah, then you need to define what that is. If it's different to a
simulator in any significant way then your statements is not about the
halting problem and can be ignored.
This is me pointing out a mistake which you are, as usual, ignoring.
Soon you will say, again, that no one can point out any errors in what
you say.
When a TM determines that [its correct pure] simulation of its input
would not halt it can correctly report that the input represents a
non-halting computation.
This is either the same as my re-write (if you remove the [...] part or
replace "its" with "a") or it is an attempt to obscure the that fact
that the "determiner" can ignore some halting computations because "it"
halted them. I am sure it the latter this as been you ruse for ages.
Anyway, you should either write the correct condition as found in every
textbook you've never read, or just come clean that you are not talking
about the halting problem.
This is me pointing out another two mistakes which you are, as usual, ignoring. Soon you will say, again, that no one can point out any
errors in what you say.
Your definition will be to confusing for people that are not computerMy definition did not use undefined terms like "simulating halt
scientists because they will believe that when the simulating halt
determiner aborts its simulation that this causes the input to halt,
thus the halt determiner is contradicting itself.
determiner" or "abort". And mine had no absurd vague "its" in it.
And this is me pointing out yet another mistake which you are, as usual, ignoring. Soon you will say, again, that no one can point out any
errors in what you say.
Of course you miss of the key conditions because you have not yet foundAnd even more simply (and obviously):
When a TM determines that its input represents a non-halting computation >>>>> it can correct report that the input represents a non-halting
computation.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
a way to write the that fools anyone:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.
Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition toWho knows? You have not defined what ⟨Ĥ⟩.qn means.
⟨Ĥ⟩.qn ?
And this is me pointing out yet another mistake which you are, as usual, ignoring. Soon you will say, again, that no one can point out any
errors in your reasoning.
In Linz, embedded_H
is the same as H (with a few tweaks) and can't correctly transition to
either Ĥ.qn or Ĥ.qy.
Your embedded_H is a mystery because it's not as in Linz.
And this is me pointing out yet another mistake which you are, as usual, ignoring.
When Ĥ is applied to ⟨Ĥ⟩OK. You are permitted to say that that is what you Ĥ does. Why should >>> anyone care?
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
A halt determiner is the same thing as a halt decider with the only
difference being that the halt determiner needs to only correctly
determine the halt status of a single input pair or a limited set of
input pairs thus has a restricted domain.
Then, for every single "input pair", there are an infinity of correct
"halt determiners". No one is interested in such trivial things.
You will probably be baffled by how I can say this, but I bet that, if
your are, you won't try to find out by trying to learn something.
A simulating halt determiner determines whether or not its input
specifies a non-halting sequence of configurations on the basis of
recognizing infinite patterns in the behavior of its simulated input
(such as the above pattern) that indicate that it would never reach
its final state in any finite number of steps of pure simulation.
That's one way to write some of these trivial Turing machines. I still
don't care about them.
Why should anyone care?
Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its
input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this
is impossible.
Linz's H does not exist. There is no input string ⟨Ĥ⟩ ⟨Ĥ⟩. There is a
proof about that. There are lots of proofs about that.
Your H may exist, but it's not Linz's.
I'm getting bored so I will skip to the chase at the end..
olcott <NoOne@NoWhere.com> writes:
On 3/6/2022 6:21 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
A halt determiner is the same thing as a halt decider with the only
difference being that the halt determiner needs to only correctly
determine the halt status of a single input pair or a limited set of
input pairs thus has a restricted domain.
Then, for every single "input pair", there are an infinity of correct
"halt determiners". No one is interested in such trivial things.
You will probably be baffled by how I can say this, but I bet that, if
your are, you won't try to find out by trying to learn something.
A simulating halt determiner determines whether or not its input
specifies a non-halting sequence of configurations on the basis of
recognizing infinite patterns in the behavior of its simulated input
(such as the above pattern) that indicate that it would never reach
its final state in any finite number of steps of pure simulation.
That's one way to write some of these trivial Turing machines. I still
don't care about them.
The simulating halt determiner that decides halting for the Linz Ĥ
defeats his proof.
No. You have not noticed what you have actually said, have you?
Why should anyone care?
Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its >>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this
is impossible.
Linz's H does not exist. There is no input string ⟨Ĥ⟩ ⟨Ĥ⟩. There is a
proof about that. There are lots of proofs about that.
Your H may exist, but it's not Linz's.
As long as the Linz Ĥ relationship to its halt determiner is
maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts defeats the Linz proof.
Not "any damn thing", no. It must be the supposed halt determiner, H,
that correctly determines it. Now that might be what you are trying to
so say with the mysterious "its", but then putting in "any damn thing"
is just daft.
More clearly, if you have an TM H such that either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
then you will have done the impossible thing what you claimed to have
done more than three years ago.
olcott <NoOne@NoWhere.com> writes:
On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
I'm getting bored so I will skip to the chase at the end..
olcott <NoOne@NoWhere.com> writes:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞As long as the Linz Ĥ relationship to its halt determiner is
maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts defeats the Linz proof.
Not "any damn thing", no. It must be the supposed halt determiner, H,
that correctly determines it. Now that might be what you are trying to
so say with the mysterious "its", but then putting in "any damn thing"
is just daft.
More clearly, if you have an TM H such that either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
then you will have done the impossible thing what you claimed to have
done more than three years ago.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
So, just to be 100% clear, you are /not/ claiming to have an TM that
does either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩
You did once and, since it's impossible, it hooked people in.
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
I'm getting bored so I will skip to the chase at the end..
olcott <NoOne@NoWhere.com> writes:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞As long as the Linz Ĥ relationship to its halt determiner is
maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts defeats the Linz proof.
Not "any damn thing", no. It must be the supposed halt determiner, H, >>>>> that correctly determines it. Now that might be what you are trying to >>>>> so say with the mysterious "its", but then putting in "any damn thing" >>>>> is just daft.
More clearly, if you have an TM H such that either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, >>>>> or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
then you will have done the impossible thing what you claimed to have >>>>> done more than three years ago.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
So, just to be 100% clear, you are /not/ claiming to have an TM that
does either
What I am claiming is that the above shows that if embedded_H rejected
its input it would be correct.
So what? We are interested in the halting problem and your claim to
have addressed the key case: to have an H such that either
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
I'm getting bored so I will skip to the chase at the end..
olcott <NoOne@NoWhere.com> writes:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞As long as the Linz Ĥ relationship to its halt determiner is
maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts defeats the Linz proof.
Not "any damn thing", no. It must be the supposed halt determiner, H, >>>>>>> that correctly determines it. Now that might be what you are trying to >>>>>>> so say with the mysterious "its", but then putting in "any damn thing" >>>>>>> is just daft.
More clearly, if you have an TM H such that either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
then you will have done the impossible thing what you claimed to have >>>>>>> done more than three years ago.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
So, just to be 100% clear, you are /not/ claiming to have an TM that >>>>> does either
What I am claiming is that the above shows that if embedded_H rejected >>>> its input it would be correct.
So what? We are interested in the halting problem and your claim to
have addressed the key case: to have an H such that either
The copy of Linz H embedded at Ĥ.qx would correctly decide that its
input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
is impossible.
No. Linz's H is such that neither
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
nor
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
is possible.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
in a finite number of steps.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
state in any finite number of steps.
Still don't care about this H of yours. You hooked people in with a lie
that you kept repeating: your H is Linz's H. At least you've come clean
now and are attempting a hand-waving definition of your H.
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 07/03/2022 22:13, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 1:16 PM, Ben Bacarisse wrote:There's no need to keep repeating that. I understand 100% that you are
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 10:53 AM, Ben Bacarisse wrote:No. Linz's H is such that neither
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
I'm getting bored so I will skip to the chase at the end.. >>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qnAs long as the Linz Ĥ relationship to its halt determiner is >>>>>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts defeats the Linz proof.
Not "any damn thing", no. It must be the supposed halt determiner, H,
that correctly determines it. Now that might be what you are trying to
so say with the mysterious "its", but then putting in "any damn thing"
is just daft.
More clearly, if you have an TM H such that either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
then you will have done the impossible thing what you claimed to have
done more than three years ago.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
So, just to be 100% clear, you are /not/ claiming to have an TM that >>>>>>>>> does either
What I am claiming is that the above shows that if embedded_H rejected >>>>>>>> its input it would be correct.
So what? We are interested in the halting problem and your claim to >>>>>>> have addressed the key case: to have an H such that either
The copy of Linz H embedded at Ĥ.qx would correctly decide that its >>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
is impossible.
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
nor
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
is possible.
Like I said I am not talking about H.
I have not been talking about H for many months.
not talking about, and don't want to talk about, your H.
When PO says "not talking about H" does that mean "not talking about
PO's H" as you're thinking, or does it mean "not talking about Linz's
H - I'm talking about Linz's Ĥ which contains a /copy/ of H that I'm
calling embedded_H" ?
I think it's both. He's walking a tightrope: if it is too obvious that
what he calls H is not Linz's H, the game will be up. But if he is
explicit that he means H as Linz does, the game is also up!
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 10:53 AM, Ben Bacarisse wrote:No. Linz's H is such that neither
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
I'm getting bored so I will skip to the chase at the end..
olcott <NoOne@NoWhere.com> writes:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞As long as the Linz Ĥ relationship to its halt determiner is >>>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts defeats the Linz proof.
Not "any damn thing", no. It must be the supposed halt determiner, H,
that correctly determines it. Now that might be what you are trying to
so say with the mysterious "its", but then putting in "any damn thing"
is just daft.
More clearly, if you have an TM H such that either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
then you will have done the impossible thing what you claimed to have >>>>>>>>> done more than three years ago.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
So, just to be 100% clear, you are /not/ claiming to have an TM that >>>>>>> does either
What I am claiming is that the above shows that if embedded_H rejected >>>>>> its input it would be correct.
So what? We are interested in the halting problem and your claim to >>>>> have addressed the key case: to have an H such that either
The copy of Linz H embedded at Ĥ.qx would correctly decide that its
input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
is impossible.
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, >>> nor
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
is possible.
Like I said I am not talking about H.
I have not been talking about H for many months.
There's no need to keep repeating that. I understand 100% that you are
not talking about, and don't want to talk about, your H.
If you really don't want to talk about your H, don't reply. I'll say
what I like about it in peace. But you can't offer any response to my
posts about it if you won't talk about it.
Also the key thing that you make sure to ignore is that it is never
the case that any decider reports on the behavior of the computation
that contains itself. Decider's are not capable of reporting on the
behavior of Turing machines they can only accept or reject finite
string inputs.
I don't ignore it, I tell you that you are wrong -- every time you bring
it up. What's more, I have, on multiple occasions, said that I can
offer you a series of exercises that, if you were to take them
seriously, might lead you to see why you are wrong.
This is one of your favourite themes. You accuse people of ignoring something that they have answered every time you bring it up. But,
unlike a crank, I will answer it every time you ask: you are wrong. Of course deciders are capable of reporting on the behaviour of Turing
machines.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
in a finite number of steps.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
state in any finite number of steps.
Still don't care about this H of yours. You hooked people in with a lie >>> that you kept repeating: your H is Linz's H. At least you've come clean >>> now and are attempting a hand-waving definition of your H.
So the situation is
that no one cares about your H and you dare not talk
about it! There is nothing substantive to discuss if you won't talk
about the big mistakes.
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 4:13 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 1:16 PM, Ben Bacarisse wrote:There's no need to keep repeating that. I understand 100% that you are
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 10:53 AM, Ben Bacarisse wrote:No. Linz's H is such that neither
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
I'm getting bored so I will skip to the chase at the end.. >>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qnAs long as the Linz Ĥ relationship to its halt determiner is >>>>>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts defeats the Linz proof.
Not "any damn thing", no. It must be the supposed halt determiner, H,
that correctly determines it. Now that might be what you are trying to
so say with the mysterious "its", but then putting in "any damn thing"
is just daft.
More clearly, if you have an TM H such that either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
then you will have done the impossible thing what you claimed to have
done more than three years ago.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
So, just to be 100% clear, you are /not/ claiming to have an TM that >>>>>>>>> does either
What I am claiming is that the above shows that if embedded_H rejected >>>>>>>> its input it would be correct.
So what? We are interested in the halting problem and your claim to >>>>>>> have addressed the key case: to have an H such that either
The copy of Linz H embedded at Ĥ.qx would correctly decide that its >>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
is impossible.
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
nor
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
is possible.
Like I said I am not talking about H.
I have not been talking about H for many months.
not talking about, and don't want to talk about, your H.
If you really don't want to talk about your H, don't reply. I'll say
what I like about it in peace. But you can't offer any response to my
posts about it if you won't talk about it.
I am only talking about the simulating halt decider that is embedded
in the middle of the Linz Ĥ at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
Oh, you are talking about Linz's H and Ĥ. OK. To "refute the proof"
(as you put it) you'd need a TM that that does either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩
But you don't (though you once said you did). Unsurprisingly, the proof
is solid. Such an H is impossible.
Also the key thing that you make sure to ignore is that it is never
the case that any decider reports on the behavior of the computation
that contains itself. Decider's are not capable of reporting on the
behavior of Turing machines they can only accept or reject finite
string inputs.
I don't ignore it, I tell you that you are wrong -- every time you bring >>> it up. What's more, I have, on multiple occasions, said that I can
offer you a series of exercises that, if you were to take them
seriously, might lead you to see why you are wrong.
This is one of your favourite themes. You accuse people of ignoring
something that they have answered every time you bring it up. But,
unlike a crank, I will answer it every time you ask: you are wrong. Of
course deciders are capable of reporting on the behaviour of Turing
machines.
So are you not interested in this fundamental error anymore? I suppose
you need to wait a bit before saying I'm ignoring this point again!
So the situation ishttps://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
in a finite number of steps.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
state in any finite number of steps.
Still don't care about this H of yours. You hooked people in with a lie >>>>> that you kept repeating: your H is Linz's H. At least you've come clean >>>>> now and are attempting a hand-waving definition of your H.
That you cannot pay attention to the fact that when the simulating
halt decider embedded within Linz Ĥ at Ĥ.qx would reject its input it
would be correct and refute the Linz proof.
No. To "refute the proof" you need an H that does either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩
but you won't even talk about H!
Anyway, with cranks, silence is often the only answer one can get, so I
can do no more than take your silence on this point as consent: you have
no such TM and never did.
After all, you've spent years walking back this claim, to the extent
that you were recently touting a decider for some made up problem of
your own that is not the halting problem.
that no one cares about your H and you dare not talk
about it! There is nothing substantive to discuss if you won't talk
about the big mistakes.
This is verbatim Linz except it has been adapted to my clearer
notational conventions:
<Linz quote>
Now Ĥ is a Turing machine, so that it will have some description
in Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ
can also be used as input string. We can therefore legitimately ask
what would happen if Ĥ is applied to ⟨Ĥ⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must
be false.
</Linz quote>
The copy of Linz H embedded at Ĥ.qx will be referred to as embedded_H
Linz is confused into believing that embedded_H is reporting on the
behavior of the computation that contains itself Ĥ applied to ⟨Ĥ⟩,
rather than the behavior specified by its input: ⟨Ĥ⟩, ⟨Ĥ⟩.
No he is not. No mention at all is made of what embedded_H reports.
The nonsense is simply that
Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
Your only hope of removing this contradiction is to change the
conditions on those lines. That's the ruse you've been trying to pull
for months with your pompous "Halt status criterion measure", but I
suppose you've realised that won't wash so, at least for today, we are
back to Linz's H and his correct criterion: halting.
But there was a time you made a bolder claim: to have an H that gave the correct answer for this one case -- a TM that does either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩, or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
But you no longer make that (impossible) claim.
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
That you act like an over-tired six year old? I do try to ignore that.
It is never the case that any decider reports on the behavior of the
computation that contains itself. Deciders are not capable of
reporting on the behavior of Turing machines they can only accept or
reject finite string inputs.
I keep addressing this. Again: you are wrong, Deciders /are/ capable of reporting on the behavior of Turing machines.
On 3/7/22 10:29 PM, olcott wrote:
On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 4:13 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 1:16 PM, Ben Bacarisse wrote:There's no need to keep repeating that. I understand 100% that you >>>>> are
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 10:53 AM, Ben Bacarisse wrote:No. Linz's H is such that neither
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
I'm getting bored so I will skip to the chase at the end.. >>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>As long as the Linz Ĥ relationship to its halt determiner is >>>>>>>>>>>>>> maintained any damn thing that correctly determines that >>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts defeats the Linz proof.
Not "any damn thing", no. It must be the supposed halt >>>>>>>>>>>>> determiner, H,
that correctly determines it. Now that might be what you >>>>>>>>>>>>> are trying to
so say with the mysterious "its", but then putting in "any >>>>>>>>>>>>> damn thing"
is just daft.
More clearly, if you have an TM H such that either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on
input ⟨Ĥ⟩,
then you will have done the impossible thing what you >>>>>>>>>>>>> claimed to have
done more than three years ago.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H
simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H
simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H
simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H
simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
So, just to be 100% clear, you are /not/ claiming to have an >>>>>>>>>>> TM that
does either
What I am claiming is that the above shows that if embedded_H >>>>>>>>>> rejected
its input it would be correct.
So what? We are interested in the halting problem and your >>>>>>>>> claim to
have addressed the key case: to have an H such that either
The copy of Linz H embedded at Ĥ.qx would correctly decide that its >>>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says
this
is impossible.
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
nor
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
is possible.
Like I said I am not talking about H.
I have not been talking about H for many months.
not talking about, and don't want to talk about, your H.
If you really don't want to talk about your H, don't reply. I'll say >>>>> what I like about it in peace. But you can't offer any response to my >>>>> posts about it if you won't talk about it.
I am only talking about the simulating halt decider that is embedded
in the middle of the Linz Ĥ at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
Oh, you are talking about Linz's H and Ĥ. OK. To "refute the proof" >>> (as you put it) you'd need a TM that that does either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩
But you don't (though you once said you did). Unsurprisingly, the proof >>> is solid. Such an H is impossible.
Also the key thing that you make sure to ignore is that it is never >>>>>> the case that any decider reports on the behavior of the computation >>>>>> that contains itself. Decider's are not capable of reporting on the >>>>>> behavior of Turing machines they can only accept or reject finite
string inputs.
I don't ignore it, I tell you that you are wrong -- every time you
bring
it up. What's more, I have, on multiple occasions, said that I can >>>>> offer you a series of exercises that, if you were to take them
seriously, might lead you to see why you are wrong.
This is one of your favourite themes. You accuse people of ignoring >>>>> something that they have answered every time you bring it up. But, >>>>> unlike a crank, I will answer it every time you ask: you are
wrong. Of
course deciders are capable of reporting on the behaviour of Turing
machines.
So are you not interested in this fundamental error anymore? I suppose >>> you need to wait a bit before saying I'm ignoring this point again!
So the situation ishttps://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final
state
in a finite number of steps.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own
final
state in any finite number of steps.
Still don't care about this H of yours. You hooked people in
with a lie
that you kept repeating: your H is Linz's H. At least you've
come clean
now and are attempting a hand-waving definition of your H.
That you cannot pay attention to the fact that when the simulating
halt decider embedded within Linz Ĥ at Ĥ.qx would reject its input it >>>> would be correct and refute the Linz proof.
No. To "refute the proof" you need an H that does either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩
but you won't even talk about H!
Anyway, with cranks, silence is often the only answer one can get, so I
can do no more than take your silence on this point as consent: you have >>> no such TM and never did.
After all, you've spent years walking back this claim, to the extent
that you were recently touting a decider for some made up problem of
your own that is not the halting problem.
that no one cares about your H and you dare not talk
about it! There is nothing substantive to discuss if you won't talk >>>>> about the big mistakes.
This is verbatim Linz except it has been adapted to my clearer
notational conventions:
<Linz quote>
Now Ĥ is a Turing machine, so that it will have some description >>>> in Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ
can also be used as input string. We can therefore legitimately ask
what would happen if Ĥ is applied to ⟨Ĥ⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The >>>> contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must
be false.
</Linz quote>
The copy of Linz H embedded at Ĥ.qx will be referred to as embedded_H >>>>
Linz is confused into believing that embedded_H is reporting on the
behavior of the computation that contains itself Ĥ applied to ⟨Ĥ⟩, >>>> rather than the behavior specified by its input: ⟨Ĥ⟩, ⟨Ĥ⟩.
No he is not. No mention at all is made of what embedded_H reports.
The nonsense is simply that
Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt. >>>
Your only hope of removing this contradiction is to change the
conditions on those lines. That's the ruse you've been trying to pull
for months with your pompous "Halt status criterion measure", but I
suppose you've realised that won't wash so, at least for today, we are
back to Linz's H and his correct criterion: halting.
But there was a time you made a bolder claim: to have an H that gave the >>> correct answer for this one case -- a TM that does either
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
But you no longer make that (impossible) claim.
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
That you act like an over-tired six year old? I do try to ignore that. >>>
It is never the case that any decider reports on the behavior of the
computation that contains itself. Deciders are not capable of
reporting on the behavior of Turing machines they can only accept or
reject finite string inputs.
I keep addressing this. Again: you are wrong, Deciders /are/ capable of >>> reporting on the behavior of Turing machines.
Deciders only compute the mapping from input finite strings to accept
or reject states. If you disagree please provide a link that proves
that deciders compute mappings from non-input non-strings.
If you don't disagree then you know that embedded_H does not compute
the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does >> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
You do like your Herring Red don't you.
NO ONE says that the decider maps something that isn't its input.
H applied to <H^> <H^> needs to figure out what its input maps to.
Mikko <mikko.levanto@iki.fi> writes:
On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:
Mikko <mikko.levanto@iki.fi> writes:
On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:But not, as far as I can see, in this case. The meaning of "decider" -- >>> a TM whose language is decidable -- is not causing any confusion. OK,
The words used don't alter the facts -- that there is no TMWords can be (and often are) used to hide facts.
satisfying Linz's 12.1 can be, loosely, stated as "there is no
decider for the strings that represent halting computations".
PO lies about what other people say and/or know about "deciders", but
the fault there is in the lying, not in the words used.
In this case the probable intent was to argue about an irrelevance in
order to draw attention from the fact that the presented soulution does
not satisfy the definitiopn (21.1) of a solution to the halting
problem.
That's possible.
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
It is never the case that any decider reports on the behavior of the
computation that contains itself. Deciders are not capable of
reporting on the behavior of Turing machines they can only accept or
reject finite string inputs.
I keep addressing this. Again: you are wrong, Deciders /are/ capable of >>> reporting on the behavior of Turing machines.
Deciders only compute the mapping from input finite strings to accept
or reject states.
Of course. No one has ever disputed this obvious fact. (You only
discovered it recently since you used to reject any talk on string
encoding as an "extraneous detail", but now this "extraneous detail"
gets top billing.)
I will repeat my offer: if you would like to learn how "deciders compute
only a function from input strings to accept/reject states" and
"deciders /are/ capable of reporting on the behavior of Turing machines"
are not contradictory, nor even in conflict, I can take you through some exercises that will help.
If you disagree please provide a link that proves that
deciders compute mappings from non-input non-strings.
If you don't disagree then you know that embedded_H does not compute
the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does >> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
(1) embedded_H is not a decider. It does not "compute the mapping from
input finite strings to accept or reject states" because it has no
accept state. You will, eventually, have to talk about H because that's where your big mistake is, and the only TM around that have accept and
reject states.
(2) Which strings a decider accepts and which it rejects is often
determined by what the strings encode. H must accept those strings of
the form <M> I such that TM M accepts input I. I.e. is accepts those
strings that encode halting computations and rejects all others.
(3) Even if all you want is a TM the "refutes the proof" (i.e. one that
is right only about that one impossible case), you must show a TM that
does either this:
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or this:
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
(4) You don't have such a TM. You have nothing.
olcott <NoOne@NoWhere.com> writes:
On 3/8/2022 7:14 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
It is never the case that any decider reports on the behavior of the >>>>>> computation that contains itself. Deciders are not capable of
reporting on the behavior of Turing machines they can only accept or >>>>>> reject finite string inputs.
I keep addressing this. Again: you are wrong, Deciders /are/ capable of >>>>> reporting on the behavior of Turing machines.
Deciders only compute the mapping from input finite strings to accept
or reject states.
Of course. No one has ever disputed this obvious fact. (You only
discovered it recently since you used to reject any talk on string
encoding as an "extraneous detail", but now this "extraneous detail"
gets top billing.)
I will repeat my offer: if you would like to learn how "deciders compute >>> only a function from input strings to accept/reject states" and
"deciders /are/ capable of reporting on the behavior of Turing machines" >>> are not contradictory, nor even in conflict, I can take you through some >>> exercises that will help.
So you now know that everyone accepts that "deciders compute only a
function from input strings to accept/reject states" and you also also
now know that "deciders /are/ capable of reporting on the behavior of
Turing machines".
You should acknowledge when you're agreed that you have been wrong about something.
If you disagree please provide a link that proves that(1) embedded_H is not a decider. It does not "compute the mapping from
deciders compute mappings from non-input non-strings.
If you don't disagree then you know that embedded_H does not compute
the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
input finite strings to accept or reject states" because it has no
accept state. You will, eventually, have to talk about H because that's >>> where your big mistake is, and the only TM around that have accept and
reject states.
It is OK that you force me to use much more accurate language because
this improves my professionalism.
You show no professionalism.
I count this as valid mentoring and appreciate your effort.
No you don't.
It is certainly technically correct to say that embedded_H is not a
decider because it lacks a final accept state. The key point that I
make is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be
correct.
No.
The Linz claim to have proven that embedded_H cannot possibly
determine the correct halt status of its input is refuted.
Linz makes no such claim.
(2) Which strings a decider accepts and which it rejects is often
determined by what the strings encode. H must accept those strings of
the form <M> I such that TM M accepts input I. I.e. is accepts those
strings that encode halting computations and rejects all others.
(3) Even if all you want is a TM the "refutes the proof" (i.e. one that
is right only about that one impossible case), you must show a TM that
does either this:
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or this:
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
(4) You don't have such a TM. You have nothing.
I note that, again, you don't dispute that you have not such H.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
is correct as I have proven many many times.
No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
"correct" nor "incorrect". It is simply a statement about what a TM
does when presented with some input. There has to be an associated
condition by which the correctness can be assessed, and you steadfastly remove the conditions that Linz so clearly gives you:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
The whole world knows why you keep omitting the condition and, instead,
claim that transitioning to Ĥ.qn "correct" with no reference to the
actual condition for correctness. When pushed, you replace the actual condition with your "it had to be aborted, honest, guv" waffle in place
of the proper condition derived from what Linz asserts about H to start
with.
It's all so tediously obvious. You won't be able to fool anyone with
it.
You (and Linz) continue to be under the mistaken notion that a halt
decider must determine the halt status of the computation that
contains itself.
A halt decider, H, must be correct about every input -- even those
strings that include something very like an encoding of H (as is the
case for Ĥ).
It almost sounds like are preparing to give up on the ruse you've been
trying to pull for the last few years, and that you are going to go back
to the "it's an invalid question nonsense" from many years ago.
This mistake would require a decider to base its accept or reject
decision on a non-string, non-input.
A decider must accept or reject every string and which one of those is
the case is determined by the input string and nothing else. Neither I,
nor Linz, nor anyone else, has suggested otherwise.
On 2022-03-08 21:20, olcott wrote:
On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
"correct" nor "incorrect". It is simply a statement about what a TM
does when presented with some input. There has to be an associated
condition by which the correctness can be assessed, and you steadfastly
remove the conditions that Linz so clearly gives you:
Ĥ.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.
The above doesn't jive with the nonsense you keep asserting elsewhere.
You keep claiming that TMs can only deal with the finite strings which
are their inputs.
But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
string nor an input to embedded_H. So why do you think that non-input non-finite string should be a valid basis for a decision criterion
whereas Ĥ applied to ⟨Ĥ⟩ should not be?
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
The whole world knows why you keep omitting the condition and, instead,
claim that transitioning to Ĥ.qn "correct" with no reference to the
actual condition for correctness. When pushed, you replace the actual
condition with your "it had to be aborted, honest, guv" waffle in place
of the proper condition derived from what Linz asserts about H to start
with.
It's all so tediously obvious. You won't be able to fool anyone with
it.
You (and Linz) continue to be under the mistaken notion that a halt
decider must determine the halt status of the computation that
contains itself.
A halt decider, H, must be correct about every input -- even those
strings that include something very like an encoding of H (as is the
case for Ĥ).
You were much sloppier in your first comment that I reponded to. Halt
deciders do not compute the halt status of non-finite string non-inputs.
It almost sounds like are preparing to give up on the ruse you've been
trying to pull for the last few years, and that you are going to go back >>> to the "it's an invalid question nonsense" from many years ago.
This mistake would require a decider to base its accept or reject
decision on a non-string, non-input.
A decider must accept or reject every string and which one of those is
the case is determined by the input string and nothing else. Neither I, >>> nor Linz, nor anyone else, has suggested otherwise.
Both you and Linz incorrectly believe that embedded_H must report on
the non-input non-finite string of Ĥ ⟨Ĥ⟩.
It's not just Ben and Linz, but every single author who has ever written about this particular proof. That's because it *isn't* a mistake.
Don't you think that it's a bit telling that everyone in the universe
who actually *understands* how Turing Machine agrees with Linz, whereas
you, who have consistently demonstrated that you've never once actually designed or worked with actual Turing Machines, are the only one who
thinks otherwise?
Maybe you start by learning the basics and leave talking about Turing Machines to people who have actually dealt with Turing Machines.
André
On 2022-03-08 13:06:16 +0000, olcott said:
On 3/8/2022 5:36 AM, Ben Bacarisse wrote:
Mikko <mikko.levanto@iki.fi> writes:
On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:
Mikko <mikko.levanto@iki.fi> writes:
On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:But not, as far as I can see, in this case. The meaning of
The words used don't alter the facts -- that there is no TMWords can be (and often are) used to hide facts.
satisfying Linz's 12.1 can be, loosely, stated as "there is no
decider for the strings that represent halting computations".
"decider" --
a TM whose language is decidable -- is not causing any confusion. OK, >>>>> PO lies about what other people say and/or know about "deciders", but >>>>> the fault there is in the lying, not in the words used.
In this case the probable intent was to argue about an irrelevance in
order to draw attention from the fact that the presented soulution does >>>> not satisfy the definitiopn (21.1) of a solution to the halting
problem.
That's possible.
I conclusively proved that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
never reaches its final state of ⟨Ĥ⟩.qn thus proving that embedded_H
would be correct to reject its input. This refutes the Linz proof that
concludes this is impossible.
Linz did not present any proof with that conclusion, so you only refuted
(or
at least tried to refute) a straw man.
Instead, Linz concluded that no Turing machine is a solution to the halting problem as defined in definition 12.1. That conclusion you have not
refuted.
Mikko
On 2022-03-09 14:15:43 +0000, olcott said:
Linz is confused into believing that the copy of H embedded at Ĥ.qx
must base its halt status decision on the non-finite string non-input
of: Ĥ applied to ⟨Ĥ⟩.
What does that "must" mean?
Linz simply infers what Ĥ does from the way it is constructed, to the
extent it can be inferred. There is no confusion, the inference is correct.
Mikko
On 2022-03-09 06:03, olcott wrote:
On 3/8/2022 11:32 PM, André G. Isaak wrote:
On 2022-03-08 21:20, olcott wrote:
On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
"correct" nor "incorrect". It is simply a statement about what a TM >>>>> does when presented with some input. There has to be an associated >>>>> condition by which the correctness can be assessed, and you
steadfastly
remove the conditions that Linz so clearly gives you:
Ĥ.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.
The above doesn't jive with the nonsense you keep asserting
elsewhere. You keep claiming that TMs can only deal with the finite
strings which are their inputs.
From the above:
⟨Ĥ⟩ is the common convention for a finite string Turing machine
description.
Ĥ is the convention for Turing machine Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.
embedded_H is the convention for referring to the copy of Linz H
embedded at Ĥ.qx.
I'm not sure why you're responding with all the above. I've read Linz
and I've read your previous posts so I already know how you are using
these terms.
But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
string nor an input to embedded_H. So why do you think that non-input
non-finite string should be a valid basis for a decision criterion
whereas Ĥ applied to ⟨Ĥ⟩ should not be?
It it always that case that every decider computes the mapping from
its finite string input to accept or reject state.
In the case of a simulating halt decider this mapping is computed on
the basis of simulating the finite string and examining the simulated
behavior for any infinite behavior patterns.
But the point is that in your criteria above you keep talking about the
"pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H"
Your embedded_H is *not* a pure simulator; it is a modified copy of what
you claim to be a simulating halt decider but with its accepting state replaced by an infinite loop.
So you are asking it to base its decision on the behaviour of some hypothetical "pure simulator" which is *not* a string nor the input to embedded_H.
Why is that allowed but it is not allowed to base a decision
on the behaviour of Ĥ (which while not a string nor an actual input is
at least a TM which embedded_H has a complete description of) applied to ⟨Ĥ⟩?
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
The whole world knows why you keep omitting the condition and,
instead,
claim that transitioning to Ĥ.qn "correct" with no reference to the >>>>> actual condition for correctness. When pushed, you replace the actual >>>>> condition with your "it had to be aborted, honest, guv" waffle in
place
of the proper condition derived from what Linz asserts about H to
start
with.
It's all so tediously obvious. You won't be able to fool anyone with >>>>> it.
You (and Linz) continue to be under the mistaken notion that a halt >>>>>> decider must determine the halt status of the computation that
contains itself.
A halt decider, H, must be correct about every input -- even those
strings that include something very like an encoding of H (as is the >>>>> case for Ĥ).
You were much sloppier in your first comment that I reponded to.
Halt deciders do not compute the halt status of non-finite string
non-inputs.
It almost sounds like are preparing to give up on the ruse you've been >>>>> trying to pull for the last few years, and that you are going to go
back
to the "it's an invalid question nonsense" from many years ago.
This mistake would require a decider to base its accept or reject
decision on a non-string, non-input.
A decider must accept or reject every string and which one of those is >>>>> the case is determined by the input string and nothing else.
Neither I,
nor Linz, nor anyone else, has suggested otherwise.
Both you and Linz incorrectly believe that embedded_H must report on
the non-input non-finite string of Ĥ ⟨Ĥ⟩.
It's not just Ben and Linz, but every single author who has ever
written about this particular proof. That's because it *isn't* a
mistake.
As it turns out to actually be even an actual universal consensus does
not guarantee truth. Prior to Pythagoras there was a universal
consensus that the Earth was flat.
<pedantry> Your facts here are incorrect. There is no evidence to
suggest that there was a universal consensus that the earth was flat
prior to Pythagoras. </pedantry>
Don't you think that it's a bit telling that everyone in the universe
who actually *understands* how Turing Machine agrees with Linz,
whereas you, who have consistently demonstrated that you've never
once actually designed or worked with actual Turing Machines, are the
only one who thinks otherwise?
Especially not when every rebuttal to my work was like yours and
entirely anchored in a misunderstanding of what I am even saying.
Maybe you start by learning the basics and leave talking about Turing
Machines to people who have actually dealt with Turing Machines.
André
I am actually starting with the establishing the fundamental
philosophical underpinnings of the notion of truth itself.
But the issue here has nothing to do with "truth" but with how Turing Machines work.
If you were to actually look at some examples of real Turing Machines
maybe you would come to understand this. When we try to construct a TM
to compute some function one of the first steps involved is to figure
out how to encode elements of the domain of that function as strings
which can actually be passed to a TM. But the TM is still expected to
process those strings in a way which actually conforms to the function
being computed.
Consider a TM which decides whether a given integer x is even or not.
There is no way in which we can pass an actual integer to a TM, since an integer is not a string. But we can easily come up with a way of
encoding the integer x as a string ⟨x⟩ which *can* be passed to an integer.
Whether the above TM accepts or rejects ⟨x⟩ *must* depend on whether x
is even or odd. Otherwise it isn't computing the function it purports to compute. And if you claim it is only responsible for determining the
mapping from the string ⟨x⟩ which is its input rather than the actual integer x, which is not its input, then any reasonable person is going
to respond with a look of utter confusion. What does it even *mean* to
talk about the evenness of ⟨x⟩ if it is not related to the evenness of the actual integer x? Strings aren't 'even' anymore than they are
'halting'.
The majority of philosophers agree that this cannot be done because
Willard Van Orman Quine has convinced them that they cannot really
know that all bachelors are unmarried.
Yes, you've already demonstrated that you are unable to appreciate the
nuance of Quine's article and have instead settled on this ridiculous interpretation. Nobody cares.
André
On 2022-03-09 19:17:10 +0000, olcott said:
<Linz:1990:320>...
Now Ĥ is a Turing machine, so that it will have some description >> in Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ
can also be used as input string. We can therefore legitimately ask
what would happen if Ĥ is applied to ⟨Ĥ⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must
be false.
</Linz:1990:320>
https://www.liarparadox.org/Linz_Proof.pdf
As quoted above Linz believes that the halt status decision of
embedded_H is based on the behavior of a non-input, non-finite string:
Ĥ applied to ⟨Ĥ⟩ rather than the actual behavior of the actual finite >> string input:
Your quote does not say so. Ĥ goes to Ĥ.qy if H goes to H.qy and to Ĥ.qn if
H goes to H.qn because that is how Ĥ is constructed. Your "based on" does not come from the quote, as is easily observed.
Mikko
olcott <polcott2@gmail.com> writes:
On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
So you now know that everyone accepts that "deciders compute only a
function from input strings to accept/reject states"
and you also also
now know that "deciders /are/ capable of reporting on the behavior of
Turing machines".
You should acknowledge when you're agreed that you have been wrong about >>> something.
I am not wrong.
I never really thought did agree that were wrong. I was just pointing
out your habit of glossing over so many points made to you. It means to
no agreement can ever be reached because you are always moving on by
making new mistakes. I will continue to assume that if you don't say
"no" you agree with what you are quoting.
Deciders never report on the actual behavior of actual
Turing machines. The closest that they get to this is is reporting on
the behavior that a finite string Turing machine description
specifies.
Pure sophistry. It's not "close" it's exact. To say that the string
<M>I encodes a halting computation is to report on the behaviour of the
TM M with input I.
You can insist, if you want, that we (and that includes you as well)
must always say things like
Ĥ.q0 ⟨Ĥ⟩⊢* Ĥ.qn
if ⟨Ĥ⟩ is the encoding of a TM, Ĥ that does not halt when run with
the input string ⟨Ĥ⟩.
but it won't change the fact that you are wrong about Ĥ.
It is OK that you force me to use much more accurate language because
this improves my professionalism.
You show no professionalism.
I am not quite yet even in the ballpark of the degree of academic
professionalism required for publication in premier computer science
journals.
You are not out of the grade-school ballpark yet -- calling clever
people nitwits, and repeating banal lines in ALL CAPS twenty times like
a petulant toddler.
Any PhD professor of computer science that is an expert in the theory
of computation on the halting problem that fully understands my work
could translate my words into academic quality in a few days.
No they could not. Academic work must be, first and foremost, correct,
and you are not. Any qualified person who understand what you are
saying can only translate it as "don't keep working on this, go help out
at the dog shelter".
By the way, why are cranks so obsessed with PhDs? It was not so long
ago (when I was a CS professor in the US sense of the word) that all the
"PhD professors" of CS had PhDs in physics or engineering because the
subject was quite new. Anyway, a PhD is always about a very narrowly
focused picece of work. Do you think someone with a PhD in database
storage for traditional Scottish Country Dances (an actual example of
someone I worked with) will even know what you are talking about?
The Linz claim to have proven that embedded_H cannot possibly
determine the correct halt status of its input is refuted.
Linz makes no such claim.
Do I have to quote his verbatim words all over again?
No, because he makes no such claim. Repeating some text where he makes
no such claim is just pointless.
<Linz>
Now Ĥ is a Turing machine, so that it will have some description
in Σ*, say ⟨Ĥ⟩. This string, in addition to being the description of Ĥ
can also be used as input string. We can therefore legitimately ask
what would happen if Ĥ is applied to ⟨Ĥ⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
I don't know weather it's deliberate, but this is not a quote form
Linz. Linz says (using your notation)
"We can therefore legitimately ask what would happen if Ĥ is applied
to ⟨Ĥ⟩. From the above, identifying M with Ĥ, we get
Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt."
So, no, he is saying nothing about the embedded H here.
He does not
even refer to it. You dishonestly put it back in the hope of suggesting
that maybe Linz was saying something about it. That's a million miles
from academic professionalism.
Linz simply writes out, in sequence, what we know about H' and the Ĥ
from the definition of what H does. The result is a contradictory:
This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must
be false.
</Linz>
(3) Even if all you want is a TM the "refutes the proof" (i.e. one that >>>>> is right only about that one impossible case), you must show a TM that >>>>> does either this:
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
or this:
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
(4) You don't have such a TM. You have nothing.
I note that, again, you don't dispute that you have not such H.
And I note it again. You don't, do you?
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
is correct as I have proven many many times.
No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
"correct" nor "incorrect". It is simply a statement about what a TM
does when presented with some input. There has to be an associated
condition by which the correctness can be assessed, and you steadfastly
remove the conditions that Linz so clearly gives you:
Ĥ.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.
Yes, yes, we know about your other not-quite-the halting problem.
You've been flip-flopping like this for months: refer to Linz, then flip
the condition to your own silly one in the hope that no one notices this
is not Linz's Ĥ any more.
You can't seriously think that's going to work any better than the old
"yes it halts, but only because ..." or the even more ludicrous "it's correct because of what would happen if line 15 were commented out".
You've been trying to pull some variation of this "it's correct because
of what would happen if it were not quote what it is" ruse for ages.
No one is buying it. Please find something more rewarding to do.
olcott <NoOne@NoWhere.com> writes:
On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
So you now know that everyone accepts that "deciders compute only a
function from input strings to accept/reject states"
This is good.
and you also also
now know that "deciders /are/ capable of reporting on the behavior of >>>>> Turing machines".
This contradicts the prior sentence:
(a) A decider only takes finite string inputs. // prior sentence
(b) A decider takes Turing machine (thus non-finite string) inputs. //
current sentence
I can't help with your poor comprehension of English.
... To say that the string <M>I encodes a halting computation is to
report on the behaviour of the TM M with input I.
Deciders take finite string inputs that specify Turing machine computations. >>
Deciders do not take Turing machine inputs.
I have offered to help with this point of comprehension but you have not taken me up on it.
Maybe you have decided that this misrepresentation
is your last best hope of distracting readers from the big mistake --
that your H rejects strings that encode halting computations.
You can insist, if you want, that we (and that includes you as well)
must always say things like
Ĥ.q0 ⟨Ĥ⟩⊢* Ĥ.qn
if ⟨Ĥ⟩ is the encoding of a TM, Ĥ that does not halt when run with
the input string ⟨Ĥ⟩.
but it won't change the fact that you are wrong about Ĥ.
Both you and Linz get confused because both you and Linz leave out key details.
Ĥ.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.
This is not Linz's Ĥ.
You have made up these conditions so that your H
can reject strings the encode halting computations, but they can't be
derived from the initial conditions Linz places on H. Your Ĥ is
irrelevant to the proof you are obsessed with.
On 2022-03-12 14:14, olcott wrote:
On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
So you now know that everyone accepts that "deciders compute only a >>>>>>> function from input strings to accept/reject states"
This is good.
and you also also
now know that "deciders /are/ capable of reporting on the
behavior of
Turing machines".
This contradicts the prior sentence:
(a) A decider only takes finite string inputs. // prior sentence
(b) A decider takes Turing machine (thus non-finite string) inputs. // >>>> current sentence
I can't help with your poor comprehension of English.
A decider cannot take a Turing machine as input and you know it.
Nowhere does he deny this.
It can only take a finite string that specifies a Turing machine.
Right. A finite string THAT SPECIFIES A TURING MACHINE.
IOW, it is given a string which provides all of the information
necessary to identify some unique Turing Machine. So while a TM cannot
take a Turing Machine as an input, it can still answer questions about
Turing Machines.
That's a fairly fundamental concept in computational theory which you
seem determined to not understand.
Turing Machines only deal with strings. This means that a function can
only be computed if (as a minimal requirement) the elements of that
domain can be ENCODED as strings. If you can encoded elements of some
domain as strings, then it might be possible for a TM to compute that function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES STRINGS.
Integers are not strings, but many functions from integers to integers
are computable by virtue of the fact that it is trivially easy to devise
ways of encoding integers as strings.
Functions from reals to reals, on the other hand, are not going to be computable precisely because the overwhelming majority of real numbers
cannot be encoded as finite strings. A function like y = √x is not computable, but one can compute some function that is "close" to this
but that limits the input/output to some arbitary degree of precision.
The set of Turing Machines is provably DENUMERABLE. That means that one
can encode TMs as finite strings. Which in turn means that a TM *can*
answer questions about Turing Machines. They just have to be encoded as finite strings before being given to a Turing Machine.
Strings which encode Turing Machines and inputs don't halt anymore than strings which encode integers have sums.
Turing Machines applied to
strings can halt and integers can have sums. But to talk about the
halting status of the STRING ⟨Ĥ⟩ ⟨Ĥ⟩ is meaningless gibberish.
André
On 2022-03-12 16:25, olcott wrote:
On 3/12/2022 3:33 PM, André G. Isaak wrote:
On 2022-03-12 14:14, olcott wrote:
On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
So you now know that everyone accepts that "deciders compute >>>>>>>>> only a
function from input strings to accept/reject states"
This is good.
and you also also
now know that "deciders /are/ capable of reporting on the
behavior of
Turing machines".
This contradicts the prior sentence:
(a) A decider only takes finite string inputs. // prior sentence
(b) A decider takes Turing machine (thus non-finite string)
inputs. //
current sentence
I can't help with your poor comprehension of English.
A decider cannot take a Turing machine as input and you know it.
Nowhere does he deny this.
It can only take a finite string that specifies a Turing machine.
Right. A finite string THAT SPECIFIES A TURING MACHINE.
IOW, it is given a string which provides all of the information
necessary to identify some unique Turing Machine. So while a TM
cannot take a Turing Machine as an input, it can still answer
questions about Turing Machines.
It is not actually answering the question about a Turing machine.
It is answering the question about the Turing machine specified by the
finite string, this distinction is crucial, and even Linz missed it.
The Turing Machine specified by the finite string *is* a Turing Machine,
so yes it is answering the question about a Turing Machine.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Everyone here (and Linz) believes that the copy of H embedded at Ĥ.qx
is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. This is off >> by exactly one level of indirection.
That's exactly what the copy of H embedded at Ĥ.qx is supposed to report
on by the very definition of the problem.
A halt decider must, *by definition*, be able to determine the halting
status of *any* arbitrary computation, so if you want to claim that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a computation different from Ĥ applied to ⟨Ĥ⟩, then you'd
better be able to show how that latter computation is to be encoded as a finite string.
So what string, according to you, encodes the computation Ĥ applied to ⟨Ĥ⟩? If these two "different" computations don't have separate encodings as strings then they are not, in fact, different computations at all.
No decider is ever supposed to report on the behavior of the
computation that contains its actual self. Deciders only report on the
behavior specified by Turing machine descriptions.
No, it is supposed to report on the halting status of the computation represented by its input. But nothing in the definition of 'halt
decider' precludes it from being given a description of a computation
which contains its actual self. If it can't answer about that question,
then it isn't meeting the definition of a halt decider which must be
able to answer about *any* computation. And in the Linz proof this is precisely what the input specifies, your nonsense about the input being
a string rather than an actual Turing Machine notwithstanding.
That's a fairly fundamental concept in computational theory which you
seem determined to not understand.
Turing Machines only deal with strings. This means that a function
can only be computed if (as a minimal requirement) the elements of
that domain can be ENCODED as strings. If you can encoded elements of
some domain as strings, then it might be possible for a TM to compute
that function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES STRINGS.
Integers are not strings, but many functions from integers to
integers are computable by virtue of the fact that it is trivially
easy to devise ways of encoding integers as strings.
Functions from reals to reals, on the other hand, are not going to be
computable precisely because the overwhelming majority of real
numbers cannot be encoded as finite strings. A function like y = √x
is not computable, but one can compute some function that is "close"
to this but that limits the input/output to some arbitary degree of
precision.
The set of Turing Machines is provably DENUMERABLE. That means that
one can encode TMs as finite strings. Which in turn means that a TM
*can* answer questions about Turing Machines. They just have to be
encoded as finite strings before being given to a Turing Machine.
Strings which encode Turing Machines and inputs don't halt anymore
than strings which encode integers have sums.
The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never >> reaches its final state of ⟨Ĥ⟩.qn in any finite number of correctly
simulated steps by the copy of H embedded at Ĥ.qx.
Finite string pairs don't *have* final states.
They don't have states at
all. It doesn't matter how you try to phrase this; your claim is simply incoherent. The finite strings which are given to a halt decider do not
have states, let alone final ones. Only the computations which they
represent have these.
André
On 2022-03-12 17:17, olcott wrote:
On 3/12/2022 5:57 PM, André G. Isaak wrote:
On 2022-03-12 16:25, olcott wrote:
On 3/12/2022 3:33 PM, André G. Isaak wrote:
On 2022-03-12 14:14, olcott wrote:
On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
So you now know that everyone accepts that "deciders compute >>>>>>>>>>> only a
function from input strings to accept/reject states"
This is good.
and you also also
now know that "deciders /are/ capable of reporting on the >>>>>>>>>>> behavior of
Turing machines".
This contradicts the prior sentence:
(a) A decider only takes finite string inputs. // prior sentence >>>>>>>> (b) A decider takes Turing machine (thus non-finite string)
inputs. //
current sentence
I can't help with your poor comprehension of English.
A decider cannot take a Turing machine as input and you know it.
Nowhere does he deny this.
It can only take a finite string that specifies a Turing machine.
Right. A finite string THAT SPECIFIES A TURING MACHINE.
IOW, it is given a string which provides all of the information
necessary to identify some unique Turing Machine. So while a TM
cannot take a Turing Machine as an input, it can still answer
questions about Turing Machines.
It is not actually answering the question about a Turing machine.
It is answering the question about the Turing machine specified by
the finite string, this distinction is crucial, and even Linz missed
it.
The Turing Machine specified by the finite string *is* a Turing
Machine, so yes it is answering the question about a Turing Machine.
Can I take your silence here as an acknowledgment that what you had
written was an error (and a very silly one at that)?
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Everyone here (and Linz) believes that the copy of H embedded at
Ĥ.qx is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. This
is off by exactly one level of indirection.
That's exactly what the copy of H embedded at Ĥ.qx is supposed to
report on by the very definition of the problem.
No Comment?
A halt decider must, *by definition*, be able to determine the
halting status of *any* arbitrary computation, so if you want to
claim that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a computation different from Ĥ applied to
⟨Ĥ⟩, then you'd better be able to show how that latter computation is >>> to be encoded as a finite string.
So what string, according to you, encodes the computation Ĥ applied
to ⟨Ĥ⟩? If these two "different" computations don't have separate
encodings as strings then they are not, in fact, different
computations at all.
No Comment?
I know you've been asked this question before and have consistently
ignored it. According to a recent post of yours that constitutes justification for a repetitive all-caps temper tantrum!
No decider is ever supposed to report on the behavior of the
computation that contains its actual self. Deciders only report on
the behavior specified by Turing machine descriptions.
No, it is supposed to report on the halting status of the computation
represented by its input. But nothing in the definition of 'halt
decider' precludes it from being given a description of a computation
which contains its actual self. If it can't answer about that
question, then it isn't meeting the definition of a halt decider
which must be able to answer about *any* computation. And in the Linz
proof this is precisely what the input specifies, your nonsense about
the input being a string rather than an actual Turing Machine
notwithstanding.
Again, is your silence a recognition that you know see your error?
That's a fairly fundamental concept in computational theory which
you seem determined to not understand.
Turing Machines only deal with strings. This means that a function
can only be computed if (as a minimal requirement) the elements of
that domain can be ENCODED as strings. If you can encoded elements
of some domain as strings, then it might be possible for a TM to
compute that function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES
STRINGS.
Integers are not strings, but many functions from integers to
integers are computable by virtue of the fact that it is trivially
easy to devise ways of encoding integers as strings.
Functions from reals to reals, on the other hand, are not going to
be computable precisely because the overwhelming majority of real
numbers cannot be encoded as finite strings. A function like y = √x >>>>> is not computable, but one can compute some function that is
"close" to this but that limits the input/output to some arbitary
degree of precision.
The set of Turing Machines is provably DENUMERABLE. That means that
one can encode TMs as finite strings. Which in turn means that a TM
*can* answer questions about Turing Machines. They just have to be
encoded as finite strings before being given to a Turing Machine.
Strings which encode Turing Machines and inputs don't halt anymore
than strings which encode integers have sums.
The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never >>>> reaches its final state of ⟨Ĥ⟩.qn in any finite number of correctly >>>> simulated steps by the copy of H embedded at Ĥ.qx.
Finite string pairs don't *have* final states.
Simulated finite string pairs ⟨Ĥ⟩ ⟨Ĥ⟩ have final states that can >> either be reached in a finite number of simulated steps or not.
The *simulation* has states which may include final states. The string
itself does not.
But SIMULATOR applied to ⟨Ĥ⟩ ⟨Ĥ⟩ and Ĥ applied to ⟨Ĥ⟩
are distinct computations which thus must be encodable by distinct
finite strings.
So are you now attempting to claim that the finite string ⟨Ĥ⟩ ⟨Ĥ⟩ is
supposed to encode the computation SIMULATOR applied to ⟨Ĥ⟩ ⟨Ĥ⟩?
If so, how do we encode Ĥ applied to ⟨Ĥ⟩ which is the computation that is actually of interest to us?
André
André G. Isaak <agisaak@gm.invalid> writes:
On 3/12/2022 5:57 PM, André G. Isaak wrote:
So what string, according to you, encodes the computation Ĥ applied
to ⟨Ĥ⟩? If these two "different" computations don't have separate >>>> encodings as strings then they are not, in fact, different
computations at all.
No Comment?
I know you've been asked this question before and have consistently
ignored it. According to a recent post of yours that constitutes
justification for a repetitive all-caps temper tantrum!
I once tried to get a direct answer to this question. I asked 12 times
in consecutive posts but never got one.
Later, on the related question of whether ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation I got this dazzling display of equivocation:
"When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
computation.
When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES NOT encode a
halting computation."
Bear in mind that at time, PO's machines were magic: two identical state transition functions could entail transitions to different states when presented with identical inputs. He has since backed off from some of
these remarks, but it never exactly clear which previous claims he would
now accept were wrong.
On 2022-03-12 19:13, olcott wrote:
On 3/12/2022 7:03 PM, André G. Isaak wrote:
On 2022-03-12 17:17, olcott wrote:
On 3/12/2022 5:57 PM, André G. Isaak wrote:
On 2022-03-12 16:25, olcott wrote:
On 3/12/2022 3:33 PM, André G. Isaak wrote:
On 2022-03-12 14:14, olcott wrote:
On 3/11/2022 8:47 PM, Ben Bacarisse wrote:Nowhere does he deny this.
olcott <NoOne@NoWhere.com> writes:
On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
So you now know that everyone accepts that "deciders >>>>>>>>>>>>> compute only a
function from input strings to accept/reject states"
This is good.
and you also also
now know that "deciders /are/ capable of reporting on the >>>>>>>>>>>>> behavior of
Turing machines".
This contradicts the prior sentence:
(a) A decider only takes finite string inputs. // prior sentence >>>>>>>>>> (b) A decider takes Turing machine (thus non-finite string) >>>>>>>>>> inputs. //
current sentence
I can't help with your poor comprehension of English.
A decider cannot take a Turing machine as input and you know it. >>>>>>>
It can only take a finite string that specifies a Turing machine. >>>>>>>Right. A finite string THAT SPECIFIES A TURING MACHINE.
IOW, it is given a string which provides all of the information
necessary to identify some unique Turing Machine. So while a TM
cannot take a Turing Machine as an input, it can still answer
questions about Turing Machines.
It is not actually answering the question about a Turing machine.
It is answering the question about the Turing machine specified by >>>>>> the finite string, this distinction is crucial, and even Linz
missed it.
The Turing Machine specified by the finite string *is* a Turing
Machine, so yes it is answering the question about a Turing Machine.
Can I take your silence here as an acknowledgment that what you had
written was an error (and a very silly one at that)?
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Everyone here (and Linz) believes that the copy of H embedded at
Ĥ.qx is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. >>>>>> This is off by exactly one level of indirection.
That's exactly what the copy of H embedded at Ĥ.qx is supposed to
report on by the very definition of the problem.
No Comment?
A halt decider must, *by definition*, be able to determine the
halting status of *any* arbitrary computation, so if you want to
claim that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a computation different from Ĥ applied
to ⟨Ĥ⟩, then you'd better be able to show how that latter
computation is to be encoded as a finite string.
So what string, according to you, encodes the computation Ĥ applied >>>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate >>>>> encodings as strings then they are not, in fact, different
computations at all.
No Comment?
I know you've been asked this question before and have consistently
ignored it. According to a recent post of yours that constitutes
justification for a repetitive all-caps temper tantrum!
No decider is ever supposed to report on the behavior of the
computation that contains its actual self. Deciders only report on >>>>>> the behavior specified by Turing machine descriptions.
No, it is supposed to report on the halting status of the
computation represented by its input. But nothing in the definition
of 'halt decider' precludes it from being given a description of a
computation which contains its actual self. If it can't answer
about that question, then it isn't meeting the definition of a halt
decider which must be able to answer about *any* computation. And
in the Linz proof this is precisely what the input specifies, your
nonsense about the input being a string rather than an actual
Turing Machine notwithstanding.
Again, is your silence a recognition that you know see your error?
That's a fairly fundamental concept in computational theory which >>>>>>> you seem determined to not understand.
Turing Machines only deal with strings. This means that a
function can only be computed if (as a minimal requirement) the
elements of that domain can be ENCODED as strings. If you can
encoded elements of some domain as strings, then it might be
possible for a TM to compute that function EVEN WHEN THOSE
ELEMENTS ARE NOT THEMSELVES STRINGS.
Integers are not strings, but many functions from integers to
integers are computable by virtue of the fact that it is
trivially easy to devise ways of encoding integers as strings.
Functions from reals to reals, on the other hand, are not going
to be computable precisely because the overwhelming majority of
real numbers cannot be encoded as finite strings. A function like >>>>>>> y = √x is not computable, but one can compute some function that >>>>>>> is "close" to this but that limits the input/output to some
arbitary degree of precision.
The set of Turing Machines is provably DENUMERABLE. That means
that one can encode TMs as finite strings. Which in turn means
that a TM *can* answer questions about Turing Machines. They just >>>>>>> have to be encoded as finite strings before being given to a
Turing Machine.
Strings which encode Turing Machines and inputs don't halt
anymore than strings which encode integers have sums.
The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never
reaches its final state of ⟨Ĥ⟩.qn in any finite number of
correctly simulated steps by the copy of H embedded at Ĥ.qx.
Finite string pairs don't *have* final states.
Simulated finite string pairs ⟨Ĥ⟩ ⟨Ĥ⟩ have final states that can >>>> either be reached in a finite number of simulated steps or not.
I am ignoring all of your other points because this single point is
the crux of the whole issue and all the other points are tangential.
Yes, that always seems to be your excuse. Every time anyone raises an objection you ignore it by declaring it 'tangential' and then claim that
no one has ever presented you with objections. Unfortunately, you have a
poor track record when it comes to deciding which things are tangential.
The *simulation* has states which may include final states. The
string itself does not.
A BASIC program that is executed in an interpreter is correctly
construed as reaching its final state.
10 PRINT "Hello, World!"
20 END
⟨Ĥ⟩ ⟨Ĥ⟩ is executed within the simulator of the copy of H embedded >> within Ĥ. This embedded_H has all of the functionality of a UTM along
with additional functionality.
The exact same string $ might encode a Turing Machine when passed to one Turing Machine, an algebraic equation when passed to another TM, and a
line of Old Church Slavonic written in Glogolitic to a third.
On 2022-03-14 19:17, olcott wrote:
On 3/12/2022 8:30 PM, André G. Isaak wrote:
The exact same string $ might encode a Turing Machine when passed to
one Turing Machine, an algebraic equation when passed to another TM,
and a line of Old Church Slavonic written in Glogolitic to a third.
None-the-less when a BASIC interpreter is running a BASIC program or a
simulating halt decider with UTM functionality is simulating a Turing
machine description in each of these two cases their input would
either reach or fail to reach a final state.
The input to a BASIC interpreter is a string representing a BASIC
program. The BASIC program might do any number of things including
reaching the end of the program, but the string itself does not do these things.
olcott <NoOne@NoWhere.com> writes:
I've shown you how to write Linz's conditions in terms of simulation:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
Feel fee to replace "halts" with "would reach its final state" (and
similarly for "does not halt") if it make you feel better. Both figures
of speech convey the same mathematical fact, but one is shorter and fits
on a line.
What you can't do, if you want to keep talking about what Linz is
talking about, is replace the reference to a UTM with embedded_H.
It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the
copy of H embedded within Ĥ would never reach the final state of this
input ⟨Ĥ⟩.qn.
Irrelevant. What matters is what follows logically from Linz's
definition of a halt decider. If you think there is any point, I'll
write it out again for you in terms of UTMs.
On 2022-03-14 19:40, olcott wrote:
On 3/14/2022 8:34 PM, André G. Isaak wrote:
On 2022-03-14 19:17, olcott wrote:
On 3/12/2022 8:30 PM, André G. Isaak wrote:
The exact same string $ might encode a Turing Machine when passed
to one Turing Machine, an algebraic equation when passed to another
TM, and a line of Old Church Slavonic written in Glogolitic to a
third.
None-the-less when a BASIC interpreter is running a BASIC program or
a simulating halt decider with UTM functionality is simulating a
Turing machine description in each of these two cases their input
would either reach or fail to reach a final state.
The input to a BASIC interpreter is a string representing a BASIC
program. The BASIC program might do any number of things including
reaching the end of the program, but the string itself does not do
these things.
The interpreted BASIC program does run and the simulated Turing
machine description does have final states.
The interpreted BASIC program is not the same thing as the string which
is the input to the BASIC interpreter. It's what happens *inside* the interpreter. You don't seem to grasp what "string" means.
On 2022-03-14 20:02, olcott wrote:
<snip nonresponsive post>
Again, I'll repeat the question which you dishonestly snipped rather
than answering. I won't bother putting it in all caps or repeating it
five times.
How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
If there are computations which cannot be encoded as strings, then it is impossible to design a universal halt decider since that means there are computations which it cannot be asked about.
André
On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
On 2022-03-14 21:07, olcott wrote:Though that would actually be a genuine contribution to computer science.
On 3/14/2022 9:05 PM, André G. Isaak wrote:There are no 'levels of indirection' when discussing Turing Machines.
On 2022-03-14 20:02, olcott wrote:
<snip nonresponsive post>
Again, I'll repeat the question which you dishonestly snipped rather
than answering. I won't bother putting it in all caps or repeating it
five times.
How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed >>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect reference
away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this >>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an input
to your decider, then your decider is broken since it must be able to
provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
If you could devise a language such that a large subset of halting and non-halting machines could be described, but not machines for which the halting status is difficult or impossible for a predefined halt decider to determine.
On Tuesday, 15 March 2022 at 14:51:44 UTC, olcott wrote:
On 3/15/2022 6:35 AM, Malcolm McLean wrote:So how would you describe a compiler which is "bootstrapped", i.e. fed its own
On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:André does not seem to be able to comprehend that a Turing machine
On 2022-03-14 21:07, olcott wrote:Though that would actually be a genuine contribution to computer science. >>> If you could devise a language such that a large subset of halting and
On 3/14/2022 9:05 PM, André G. Isaak wrote:There are no 'levels of indirection' when discussing Turing Machines.
On 2022-03-14 20:02, olcott wrote:
<snip nonresponsive post>
Again, I'll repeat the question which you dishonestly snipped rather >>>>>> than answering. I won't bother putting it in all caps or repeating it >>>>>> five times.
How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect reference
away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an input
to your decider, then your decider is broken since it must be able to
provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
non-halting machines could be described, but not machines for which the
halting status is difficult or impossible for a predefined halt decider to determine.
decider cannot possibly have its own self or an encoding of its own self
as its input. The closest thing possible that it can have is an encoding
of another different instance of itself.
source code?
On 3/15/2022 10:44 AM, Malcolm McLean wrote:
This is one of your best Peter. Along the way you've had 100s ofSo how would you describe a compiler which is "bootstrapped", i.e. fed
its own
source code?
A compiler that is fed its own source-code is not the same because the compiler does not execute this source-code.
On 3/15/2022 10:11 AM, olcott wrote:
On 3/15/2022 10:44 AM, Malcolm McLean wrote:
<MAJOR SNIP>
This is one of your best Peter. Along the way you've had 100s ofSo how would you describe a compiler which is "bootstrapped", i.e.
fed its own
source code?
A compiler that is fed its own source-code is not the same because the
compiler does not execute this source-code.
messages that have said that simulation as a basis for a Halting Problem solution is hopeless. Of course you pay no attention because it's
unlikely you understood what you were being told. So here you are
looping back over years of the same bone headed approach.
Let's start with a few basics:
Nothing executes source code; even an interpreter ingests it first.
On 3/15/2022 1:44 PM, olcott wrote:
On 3/15/2022 1:58 PM, Jeff Barnett wrote:
On 3/15/2022 10:11 AM, olcott wrote:
On 3/15/2022 10:44 AM, Malcolm McLean wrote:
<MAJOR SNIP>
This is one of your best Peter. Along the way you've had 100s ofSo how would you describe a compiler which is "bootstrapped", i.e.
fed its own
source code?
A compiler that is fed its own source-code is not the same because
the compiler does not execute this source-code.
messages that have said that simulation as a basis for a Halting
Problem solution is hopeless. Of course you pay no attention because
it's unlikely you understood what you were being told. So here you
are looping back over years of the same bone headed approach.
Let's start with a few basics:
Nothing executes source code; even an interpreter ingests it first.
A compiler the compiles its own source-code is nothing at all like
executing this source code.
You really do have rocks in your head. Think for at least 2 seconds
before responding and getting it all wrong. The mistakes you are making
with the above statement are so basic that I hardly know where to start.
As I've been told many times it's harder to teach Kindergarten than grad students. And in this instance, with you, we have a sixty year old
crawling around in diapers.
An interpreter that interprets source code can be reasonably construed
as running this source code.
Perhaps. The issue is it really doesn't know that it is it's own source
code, does it? And, in fact, neither it nor any observer is aware of any vicious self reference. Only a dunce would worry about it. You do worry
don't you?
On 2022-03-15 08:51, olcott wrote:
On 3/15/2022 6:35 AM, Malcolm McLean wrote:
On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
On 2022-03-14 21:07, olcott wrote:Though that would actually be a genuine contribution to computer
On 3/14/2022 9:05 PM, André G. Isaak wrote:There are no 'levels of indirection' when discussing Turing Machines.
On 2022-03-14 20:02, olcott wrote:
<snip nonresponsive post>
Again, I'll repeat the question which you dishonestly snipped rather >>>>>> than answering. I won't bother putting it in all caps or repeating it >>>>>> five times.
How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect >>>>> reference
away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an >>>> input
to your decider, then your decider is broken since it must be able to
provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
science.
If you could devise a language such that a large subset of halting and
non-halting machines could be described, but not machines for which the
halting status is difficult or impossible for a predefined halt
decider to determine.
André does not seem to be able to comprehend that a Turing machine
decider cannot possibly have its own self or an encoding of its own
self as its input. The closest thing possible that it can have is an
encoding of another different instance of itself.
Computations don't have different instances. What would it even mean to 'instantiate' a computation?
André
On 2022-03-15 08:51, olcott wrote:
On 3/15/2022 6:35 AM, Malcolm McLean wrote:
On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
On 2022-03-14 21:07, olcott wrote:Though that would actually be a genuine contribution to computer
On 3/14/2022 9:05 PM, André G. Isaak wrote:There are no 'levels of indirection' when discussing Turing Machines.
On 2022-03-14 20:02, olcott wrote:
<snip nonresponsive post>
Again, I'll repeat the question which you dishonestly snipped rather >>>>>> than answering. I won't bother putting it in all caps or repeating it >>>>>> five times.
How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect >>>>> reference
away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an >>>> input
to your decider, then your decider is broken since it must be able to
provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
science.
If you could devise a language such that a large subset of halting and
non-halting machines could be described, but not machines for which the
halting status is difficult or impossible for a predefined halt
decider to determine.
André does not seem to be able to comprehend that a Turing machine
decider cannot possibly have its own self or an encoding of its own
self as its input. The closest thing possible that it can have is an
encoding of another different instance of itself.
Computations don't have different instances. What would it even mean to 'instantiate' a computation?
André
On 3/15/2022 4:02 PM, olcott wrote:
On 3/15/2022 4:48 PM, Jeff Barnett wrote:You soiled your diapers again. I said nothing of the sort. I will say it
On 3/15/2022 1:44 PM, olcott wrote:
On 3/15/2022 1:58 PM, Jeff Barnett wrote:
On 3/15/2022 10:11 AM, olcott wrote:
On 3/15/2022 10:44 AM, Malcolm McLean wrote:
<MAJOR SNIP>
This is one of your best Peter. Along the way you've had 100s ofSo how would you describe a compiler which is "bootstrapped",
i.e. fed its own
source code?
A compiler that is fed its own source-code is not the same because >>>>>> the compiler does not execute this source-code.
messages that have said that simulation as a basis for a Halting
Problem solution is hopeless. Of course you pay no attention
because it's unlikely you understood what you were being told. So
here you are looping back over years of the same bone headed approach. >>>>>
Let's start with a few basics:
Nothing executes source code; even an interpreter ingests it first.
A compiler the compiles its own source-code is nothing at all like
executing this source code.
You really do have rocks in your head. Think for at least 2 seconds
before responding and getting it all wrong. The mistakes you are
making with the above statement are so basic that I hardly know where
to start. As I've been told many times it's harder to teach
Kindergarten than grad students. And in this instance, with you, we
have a sixty year old crawling around in diapers.
An interpreter that interprets source code can be reasonably
construed as running this source code.
Perhaps. The issue is it really doesn't know that it is it's own
source code, does it? And, in fact, neither it nor any observer is
aware of any vicious self reference. Only a dunce would worry about
it. You do worry don't you?
In other words you are saying that no one is bright enough to be able
to detect what is essentially infinite recursion.
now though, nobody is intelligent enough to systematically (by
algorithm) spot infinite recursion. God can't do it either. It's not theoretically possible. Only an ignorant nitwit would not know that and prattle on for years about it.
By the way, if you think either you or a program you write can spot
infinite recursion in, say, a year I'd love to make a sizable bet that
you can not. In the past several of us have proposed such test cases to
you. You haven't tried any of them. In fact you clipped these problem descriptions out of the original messages when you responded.
It's amazing that you make the same mistakes over and over again. If you could spot the infinite recursion/iteration in that small mind of yours
you would be doing something more sane with your time.
On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:
On 3/16/2022 2:21 AM, Jeff Barnett wrote:It can often be detected.
On 3/15/2022 4:02 PM, olcott wrote:I already have a group of many experts that concur that infinite
On 3/15/2022 4:48 PM, Jeff Barnett wrote:You soiled your diapers again. I said nothing of the sort. I will say it >>> now though, nobody is intelligent enough to systematically (by
On 3/15/2022 1:44 PM, olcott wrote:
On 3/15/2022 1:58 PM, Jeff Barnett wrote:
On 3/15/2022 10:11 AM, olcott wrote:
On 3/15/2022 10:44 AM, Malcolm McLean wrote:
<MAJOR SNIP>
This is one of your best Peter. Along the way you've had 100s of >>>>>>> messages that have said that simulation as a basis for a Halting >>>>>>> Problem solution is hopeless. Of course you pay no attentionSo how would you describe a compiler which is "bootstrapped", >>>>>>>>> i.e. fed its own
source code?
A compiler that is fed its own source-code is not the same because >>>>>>>> the compiler does not execute this source-code.
because it's unlikely you understood what you were being told. So >>>>>>> here you are looping back over years of the same bone headed approach. >>>>>>>
Let's start with a few basics:
Nothing executes source code; even an interpreter ingests it first. >>>>>>>
A compiler the compiles its own source-code is nothing at all like >>>>>> executing this source code.
You really do have rocks in your head. Think for at least 2 seconds
before responding and getting it all wrong. The mistakes you are
making with the above statement are so basic that I hardly know where >>>>> to start. As I've been told many times it's harder to teach
Kindergarten than grad students. And in this instance, with you, we
have a sixty year old crawling around in diapers.
An interpreter that interprets source code can be reasonably
construed as running this source code.
Perhaps. The issue is it really doesn't know that it is it's own
source code, does it? And, in fact, neither it nor any observer is
aware of any vicious self reference. Only a dunce would worry about
it. You do worry don't you?
In other words you are saying that no one is bright enough to be able
to detect what is essentially infinite recursion.
algorithm) spot infinite recursion. God can't do it either. It's not
theoretically possible. Only an ignorant nitwit would not know that and
prattle on for years about it.
recursion can be detected and the criterion measure by which it is
correctly detected.
In real programs which are basically imperative, with a small amount of recursion,
written by human programmers, infinite recursion can usually be detected quite easily.
However it's possible to recast famous open problems in mathematics as recursive routines which either eventualy return or never return, depending on
whether the conjecture is true or false. Of course you can't detect infinite recursion in these cases by using a simple toolkit of pattern matching.
On Wednesday, 16 March 2022 at 16:17:38 UTC, olcott wrote:
On 3/16/2022 11:06 AM, Malcolm McLean wrote:That's right. For example Goldbach's conjecture is that every even number above
On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:Currently undecidable because a proof is currently unknown is not the
On 3/16/2022 2:21 AM, Jeff Barnett wrote:It can often be detected.
On 3/15/2022 4:02 PM, olcott wrote:I already have a group of many experts that concur that infinite
On 3/15/2022 4:48 PM, Jeff Barnett wrote:You soiled your diapers again. I said nothing of the sort. I will say it >>>>> now though, nobody is intelligent enough to systematically (by
On 3/15/2022 1:44 PM, olcott wrote:
On 3/15/2022 1:58 PM, Jeff Barnett wrote:
On 3/15/2022 10:11 AM, olcott wrote:
On 3/15/2022 10:44 AM, Malcolm McLean wrote:
<MAJOR SNIP>
This is one of your best Peter. Along the way you've had 100s of >>>>>>>>> messages that have said that simulation as a basis for a Halting >>>>>>>>> Problem solution is hopeless. Of course you pay no attention >>>>>>>>> because it's unlikely you understood what you were being told. So >>>>>>>>> here you are looping back over years of the same bone headed approach.So how would you describe a compiler which is "bootstrapped", >>>>>>>>>>> i.e. fed its own
source code?
A compiler that is fed its own source-code is not the same because >>>>>>>>>> the compiler does not execute this source-code.
Let's start with a few basics:
Nothing executes source code; even an interpreter ingests it first. >>>>>>>>>
A compiler the compiles its own source-code is nothing at all like >>>>>>>> executing this source code.
You really do have rocks in your head. Think for at least 2 seconds >>>>>>> before responding and getting it all wrong. The mistakes you are >>>>>>> making with the above statement are so basic that I hardly know where >>>>>>> to start. As I've been told many times it's harder to teach
Kindergarten than grad students. And in this instance, with you, we >>>>>>> have a sixty year old crawling around in diapers.
An interpreter that interprets source code can be reasonably
construed as running this source code.
Perhaps. The issue is it really doesn't know that it is it's own >>>>>>> source code, does it? And, in fact, neither it nor any observer is >>>>>>> aware of any vicious self reference. Only a dunce would worry about >>>>>>> it. You do worry don't you?
In other words you are saying that no one is bright enough to be able >>>>>> to detect what is essentially infinite recursion.
algorithm) spot infinite recursion. God can't do it either. It's not >>>>> theoretically possible. Only an ignorant nitwit would not know that and >>>>> prattle on for years about it.
recursion can be detected and the criterion measure by which it is
correctly detected.
In real programs which are basically imperative, with a small amount of recursion,
written by human programmers, infinite recursion can usually be detected quite easily.
However it's possible to recast famous open problems in mathematics as
recursive routines which either eventualy return or never return, depending on
whether the conjecture is true or false. Of course you can't detect infinite
recursion in these cases by using a simple toolkit of pattern matching.
same as "undecidable" because of self contradiction such as the Liar
Paradox (Upon which the Tarski Undefinability Theorem is based).
two is the sum of two primes. If you have a universal infinite recursion detector,
it would be easy to prove or disprove this conjecture by writing a function which
terminates when it finds a counterexample, and running it through the detector.
But of course we can't write a universal infinite recursion detector.
What you might be able to do is write a special purpose detector, and prove or
disprove the conjecture that way. But you can't do that by using a few simple techniques, or it would have been done already. What's more likely is that the conjecture will be solved by mathematical techniques, and then you could dectect functions which enumerate the conjecture, and decide them based on prior knowledge. However that's difficult to do, and not really of much interest
to anyone.
On 16/03/2022 14:15, olcott wrote:
On 3/16/2022 2:21 AM, Jeff Barnett wrote:
On 3/15/2022 4:02 PM, olcott wrote:
On 3/15/2022 4:48 PM, Jeff Barnett wrote:You soiled your diapers again. I said nothing of the sort. I will say
On 3/15/2022 1:44 PM, olcott wrote:
On 3/15/2022 1:58 PM, Jeff Barnett wrote:
On 3/15/2022 10:11 AM, olcott wrote:
On 3/15/2022 10:44 AM, Malcolm McLean wrote:
<MAJOR SNIP>
This is one of your best Peter. Along the way you've had 100s of >>>>>>> messages that have said that simulation as a basis for a Halting >>>>>>> Problem solution is hopeless. Of course you pay no attentionSo how would you describe a compiler which is "bootstrapped", >>>>>>>>> i.e. fed its own
source code?
A compiler that is fed its own source-code is not the same
because the compiler does not execute this source-code.
because it's unlikely you understood what you were being told. So >>>>>>> here you are looping back over years of the same bone headed
approach.
Let's start with a few basics:
Nothing executes source code; even an interpreter ingests it first. >>>>>>>
A compiler the compiles its own source-code is nothing at all like >>>>>> executing this source code.
You really do have rocks in your head. Think for at least 2 seconds
before responding and getting it all wrong. The mistakes you are
making with the above statement are so basic that I hardly know
where to start. As I've been told many times it's harder to teach
Kindergarten than grad students. And in this instance, with you, we
have a sixty year old crawling around in diapers.
An interpreter that interprets source code can be reasonably
construed as running this source code.
Perhaps. The issue is it really doesn't know that it is it's own
source code, does it? And, in fact, neither it nor any observer is
aware of any vicious self reference. Only a dunce would worry about
it. You do worry don't you?
In other words you are saying that no one is bright enough to be
able to detect what is essentially infinite recursion.
it now though, nobody is intelligent enough to systematically (by
algorithm) spot infinite recursion. God can't do it either. It's not
theoretically possible. Only an ignorant nitwit would not know that
and prattle on for years about it.
I already have a group of many experts that concur that infinite
recursion can be detected and the criterion measure by which it is
correctly detected.
I'm afraid that you lack the intellect to understand exactly what other people are saying on technical issues. How many times have you quoted
me (and others here) as supporting something you've claimed, whereas it
turns out you had just misunderstood some remark that had been made?
[Answer: lots of times!]
You also have a habit of going elsewhere, and "tricking" the people
there into "agreeing" with some claim you've made here by not properly explaining the full context of your claim. Then you come back here selectively quoting some "expert" to suggest he is supporting you.
[Like when you went to the x86 group and showed them your "trace" asking
them if they could see what's going on, and got one of them to say "it's looping...". You failed to mention the trace was not the "processor
trace" they would naturally expect, and that there was simulation
involved, and that your trace was in fact some kind of "merged
simulation trace", and that you were using this trace to disprove the
Halting Problem theorem.]
It's been pointed out to you many times that algorithms exhist that can identify /some/ infinite loops/recursions as such, but no algorithm
detects ALL non-halting behaviour.
And specifically, your test (looking for more than one call to a
particular address etc.) is /unsound/ when you try to use it on your
"merged simulation" trace. No expert would say otherwise if they had
been given the full context, so probably you've just tricked someone
again...
Mike.
On 16/03/2022 17:20, olcott wrote:
On 3/16/2022 12:04 PM, Mike Terry wrote:
On 16/03/2022 14:15, olcott wrote:
On 3/16/2022 2:21 AM, Jeff Barnett wrote:
On 3/15/2022 4:02 PM, olcott wrote:
On 3/15/2022 4:48 PM, Jeff Barnett wrote:You soiled your diapers again. I said nothing of the sort. I will
On 3/15/2022 1:44 PM, olcott wrote:
On 3/15/2022 1:58 PM, Jeff Barnett wrote:
On 3/15/2022 10:11 AM, olcott wrote:
On 3/15/2022 10:44 AM, Malcolm McLean wrote:
<MAJOR SNIP>
This is one of your best Peter. Along the way you've had 100s >>>>>>>>> of messages that have said that simulation as a basis for aSo how would you describe a compiler which is "bootstrapped", >>>>>>>>>>> i.e. fed its own
source code?
A compiler that is fed its own source-code is not the same >>>>>>>>>> because the compiler does not execute this source-code.
Halting Problem solution is hopeless. Of course you pay no
attention because it's unlikely you understood what you were >>>>>>>>> being told. So here you are looping back over years of the same >>>>>>>>> bone headed approach.
Let's start with a few basics:
Nothing executes source code; even an interpreter ingests it >>>>>>>>> first.
A compiler the compiles its own source-code is nothing at all
like executing this source code.
You really do have rocks in your head. Think for at least 2
seconds before responding and getting it all wrong. The mistakes >>>>>>> you are making with the above statement are so basic that I
hardly know where to start. As I've been told many times it's
harder to teach Kindergarten than grad students. And in this
instance, with you, we have a sixty year old crawling around in
diapers.
An interpreter that interprets source code can be reasonably
construed as running this source code.
Perhaps. The issue is it really doesn't know that it is it's own >>>>>>> source code, does it? And, in fact, neither it nor any observer
is aware of any vicious self reference. Only a dunce would worry >>>>>>> about it. You do worry don't you?
In other words you are saying that no one is bright enough to be
able to detect what is essentially infinite recursion.
say it now though, nobody is intelligent enough to systematically
(by algorithm) spot infinite recursion. God can't do it either.
It's not theoretically possible. Only an ignorant nitwit would not
know that and prattle on for years about it.
I already have a group of many experts that concur that infinite
recursion can be detected and the criterion measure by which it is
correctly detected.
I'm afraid that you lack the intellect to understand exactly what
other people are saying on technical issues. How many times have you
quoted me (and others here) as supporting something you've claimed,
whereas it turns out you had just misunderstood some remark that had
been made? [Answer: lots of times!]
You also have a habit of going elsewhere, and "tricking" the people
there into "agreeing" with some claim you've made here by not
properly explaining the full context of your claim. Then you come
back here selectively quoting some "expert" to suggest he is
supporting you. [Like when you went to the x86 group and showed them
your "trace" asking them if they could see what's going on, and got
one of them to say "it's looping...". You failed to mention the
trace was not the "processor trace" they would naturally expect, and
that there was simulation involved, and that your trace was in fact
some kind of "merged simulation trace", and that you were using this
trace to disprove the Halting Problem theorem.]
It's been pointed out to you many times that algorithms exhist that
can identify /some/ infinite loops/recursions as such, but no
algorithm detects ALL non-halting behaviour.
And specifically, your test (looking for more than one call to a
particular address etc.) is /unsound/ when you try to use it on your
"merged simulation" trace. No expert would say otherwise if they had
been given the full context, so probably you've just tricked someone
again...
Mike.
None-the-less is is self-evident that the input presented to the copy
of the Linz H embedded at Ĥ.qx does specify infinitely nested
simulation to simulating halt decider embedded_H thus proving that a
transition to Ĥ.qn by embedded_H would be correct.
You mean self-evident TO YOU. To people who have an understanding of
TMs it is simply wrong or meaningless (depending on how tolerant people
are of your wishy-washy phrasing).
Mike.
On 2022-03-15 15:44, olcott wrote:
On 3/15/2022 3:24 PM, André G. Isaak wrote:
On 2022-03-15 08:51, olcott wrote:
On 3/15/2022 6:35 AM, Malcolm McLean wrote:
On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
On 2022-03-14 21:07, olcott wrote:Though that would actually be a genuine contribution to computer
On 3/14/2022 9:05 PM, André G. Isaak wrote:There are no 'levels of indirection' when discussing Turing Machines. >>>>>>
On 2022-03-14 20:02, olcott wrote:
<snip nonresponsive post>
Again, I'll repeat the question which you dishonestly snipped
rather
than answering. I won't bother putting it in all caps or
repeating it
five times.
How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be >>>>>>>> passed
to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩? >>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect >>>>>>> reference
away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass >>>>>>> this
exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an >>>>>> input
to your decider, then your decider is broken since it must be able to >>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
science.
If you could devise a language such that a large subset of halting and >>>>> non-halting machines could be described, but not machines for which
the
halting status is difficult or impossible for a predefined halt
decider to determine.
André does not seem to be able to comprehend that a Turing machine
decider cannot possibly have its own self or an encoding of its own
self as its input. The closest thing possible that it can have is an
encoding of another different instance of itself.
Computations don't have different instances. What would it even mean
to 'instantiate' a computation?
André
A Turing machine UTM that is simulating its own Turing machine
description is two distinct instances: (executed and simulated) even
if computer science does not bother to pay attention to this level of
detail, or have the terminology to express it.
You're confusing computations and Turing Machines.
If you pass a UTM a description of itself, it will determine what UTM
applied to an empty tape will do.
UTM ⟨UTM⟩
and
UTM ∅
are entirely distinct computations.
They are not different 'instances'
of some computation. Every "instance" of
M ⟨I⟩
is the exact same computation. So there is no point in talking about "instances".
Do you actually understand what instantiation means?
André
On 2022-03-16 14:22, olcott wrote:
On 3/16/2022 3:11 PM, André G. Isaak wrote:
On 2022-03-15 15:44, olcott wrote:
<snip>
A Turing machine UTM that is simulating its own Turing machine
description is two distinct instances: (executed and simulated) even
if computer science does not bother to pay attention to this level
of detail, or have the terminology to express it.
You're confusing computations and Turing Machines.
If you pass a UTM a description of itself, it will determine what UTM
applied to an empty tape will do.
UTM ⟨UTM⟩
and
UTM ∅
are entirely distinct computations.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In the above: Ĥ applied to ⟨Ĥ⟩ and the ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H
vary by exactly one level of indirect reference.
Which has absolutely nothing to do with my point since only *one* of the above is a computation; Ĥ applied to ⟨Ĥ⟩. The other, ⟨Ĥ⟩ ⟨Ĥ⟩ is a string
which describes a computation, and the computation it describes is Ĥ
applied to ⟨Ĥ⟩ which is the computation which your 'embedded_H' must answer about.
olcott <NoOne@NoWhere.com> writes:
On 3/12/2022 8:55 PM, Ben Bacarisse wrote:
André G. Isaak <agisaak@gm.invalid> writes:
I once tried to get a direct answer to this question. I asked 12 timesOn 3/12/2022 5:57 PM, André G. Isaak wrote:
So what string, according to you, encodes the computation Ĥ applied >>>>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate >>>>>> encodings as strings then they are not, in fact, different
computations at all.
No Comment?
I know you've been asked this question before and have consistently
ignored it. According to a recent post of yours that constitutes
justification for a repetitive all-caps temper tantrum!
in consecutive posts but never got one.
Later, on the related question of whether ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
computation I got this dazzling display of equivocation:
"When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
computation.
When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES NOT encode a
halting computation."
Bear in mind that at time, PO's machines were magic: two identical state >>> transition functions could entail transitions to different states when
presented with identical inputs. He has since backed off from some of
these remarks, but it never exactly clear which previous claims he would >>> now accept were wrong.
None-the-less...
You mean you won't comment on the above but would rather present new
junk about BASIC. Oh well... I can't stop you.
olcott <NoOne@NoWhere.com> writes:
On 3/12/2022 9:59 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
I've shown you how to write Linz's conditions in terms of simulation:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
Feel fee to replace "halts" with "would reach its final state" (and
similarly for "does not halt") if it make you feel better. Both figures >>> of speech convey the same mathematical fact, but one is shorter and fits >>> on a line.
What you can't do, if you want to keep talking about what Linz is
talking about, is replace the reference to a UTM with embedded_H.
Embedded_H has a full UTM as a part of it.
Not in dispute.
The Linz ⊢* wild card state transition allows for a UTM simulation to
be a part of the decision process.
Not in dispute.
Embedded_H determines whether or not its simulated input would ever
reach its final state if embedded_H remained in pure UTM mode.
Not in dispute.
It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by theIrrelevant. What matters is what follows logically from Linz's
copy of H embedded within Ĥ would never reach the final state of this >>>> input ⟨Ĥ⟩.qn.
definition of a halt decider. If you think there is any point, I'll
write it out again for you in terms of UTMs.
If the input to embedded_H never halts and embedded_H correctly
reports this that is most relevant.
Not in dispute (except for the poor wording).
If you want to know why you are still wrong after 14 years, you are
going to have to learn to follow what other people are saying. Of
course, if you did that, you'd see all your mistakes, so you are much
better off remaining ignorant of what's being said to you.
olcott <NoOne@NoWhere.com> writes:
On 3/16/2022 8:30 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/12/2022 9:59 PM, Ben Bacarisse wrote:Not in dispute.
olcott <NoOne@NoWhere.com> writes:
I've shown you how to write Linz's conditions in terms of simulation: >>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
Feel fee to replace "halts" with "would reach its final state" (and
similarly for "does not halt") if it make you feel better. Both figures >>>>> of speech convey the same mathematical fact, but one is shorter and fits >>>>> on a line.
What you can't do, if you want to keep talking about what Linz is
talking about, is replace the reference to a UTM with embedded_H.
Embedded_H has a full UTM as a part of it.
The Linz ⊢* wild card state transition allows for a UTM simulation to >>>> be a part of the decision process.Not in dispute.
Embedded_H determines whether or not its simulated input would everNot in dispute.
reach its final state if embedded_H remained in pure UTM mode.
Not in dispute (except for the poor wording).It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by theIrrelevant. What matters is what follows logically from Linz's
copy of H embedded within Ĥ would never reach the final state of this >>>>>> input ⟨Ĥ⟩.qn.
definition of a halt decider. If you think there is any point, I'll >>>>> write it out again for you in terms of UTMs.
If the input to embedded_H never halts and embedded_H correctly
reports this that is most relevant.
If you want to know why you are still wrong after 14 years, you are
going to have to learn to follow what other people are saying. Of
course, if you did that, you'd see all your mistakes, so you are much
better off remaining ignorant of what's being said to you.
When the Linz H is embedded in the Linz Ĥ as a simulating halt decider
then the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H presents infinitely nested >> simulation to embedded_H thus making the embedded_H transition to Ĥ.qn
correct.
No.
This refutes the Linz proof because the Linz proof concludes that Ĥ
applied to ⟨Ĥ⟩ results in a contradiction. (see direct quote below).
It refutes nothing.
olcott <NoOne@NoWhere.com> writes:
On 3/16/2022 8:30 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/12/2022 9:59 PM, Ben Bacarisse wrote:Not in dispute.
olcott <NoOne@NoWhere.com> writes:
I've shown you how to write Linz's conditions in terms of simulation: >>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
Feel fee to replace "halts" with "would reach its final state" (and
similarly for "does not halt") if it make you feel better. Both figures >>>>> of speech convey the same mathematical fact, but one is shorter and fits >>>>> on a line.
What you can't do, if you want to keep talking about what Linz is
talking about, is replace the reference to a UTM with embedded_H.
Embedded_H has a full UTM as a part of it.
The Linz ⊢* wild card state transition allows for a UTM simulation to >>>> be a part of the decision process.Not in dispute.
Embedded_H determines whether or not its simulated input would everNot in dispute.
reach its final state if embedded_H remained in pure UTM mode.
Not in dispute (except for the poor wording).It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by theIrrelevant. What matters is what follows logically from Linz's
copy of H embedded within Ĥ would never reach the final state of this >>>>>> input ⟨Ĥ⟩.qn.
definition of a halt decider. If you think there is any point, I'll >>>>> write it out again for you in terms of UTMs.
If the input to embedded_H never halts and embedded_H correctly
reports this that is most relevant.
If you want to know why you are still wrong after 14 years, you are
going to have to learn to follow what other people are saying. Of
course, if you did that, you'd see all your mistakes, so you are much
better off remaining ignorant of what's being said to you.
When the Linz H is embedded in the Linz Ĥ as a simulating halt decider
then the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H presents infinitely nested >> simulation to embedded_H thus making the embedded_H transition to Ĥ.qn
correct.
No.
olcott <NoOne@NoWhere.com> writes:
On 3/18/2022 11:40 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/16/2022 8:30 PM, Ben Bacarisse wrote:No.
olcott <NoOne@NoWhere.com> writes:
On 3/12/2022 9:59 PM, Ben Bacarisse wrote:Not in dispute.
olcott <NoOne@NoWhere.com> writes:Embedded_H has a full UTM as a part of it.
I've shown you how to write Linz's conditions in terms of simulation: >>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
Feel fee to replace "halts" with "would reach its final state" (and >>>>>>> similarly for "does not halt") if it make you feel better. Both figures
of speech convey the same mathematical fact, but one is shorter and fits
on a line.
What you can't do, if you want to keep talking about what Linz is >>>>>>> talking about, is replace the reference to a UTM with embedded_H. >>>>>>
The Linz ⊢* wild card state transition allows for a UTM simulation to >>>>>> be a part of the decision process.Not in dispute.
Embedded_H determines whether or not its simulated input would ever >>>>>> reach its final state if embedded_H remained in pure UTM mode.Not in dispute.
Not in dispute (except for the poor wording).It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by theIrrelevant. What matters is what follows logically from Linz's
copy of H embedded within Ĥ would never reach the final state of this >>>>>>>> input ⟨Ĥ⟩.qn.
definition of a halt decider. If you think there is any point, I'll >>>>>>> write it out again for you in terms of UTMs.
If the input to embedded_H never halts and embedded_H correctly
reports this that is most relevant.
If you want to know why you are still wrong after 14 years, you are
going to have to learn to follow what other people are saying. Of
course, if you did that, you'd see all your mistakes, so you are much >>>>> better off remaining ignorant of what's being said to you.
When the Linz H is embedded in the Linz Ĥ as a simulating halt decider >>>> then the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H presents infinitely nested >>>> simulation to embedded_H thus making the embedded_H transition to Ĥ.qn >>>> correct.
The reason that you only have a dogmatic reply rather than any
supporting reasoning is that I am correct.
No, it's because there is no evidence that you can accept the
explanations that are put to you.
Do you really think it's worth my
while explaining, yet again, that re-defining what H should do is just pointless?
I'll take the time to explain if you ask intelligent questions, but my repeating that reply to what you keep cutting and pasting is just a
waste of time.
No one can find any error in the following only because there is no
error to be found.
You can't see the error. That's not the same thing at all.
I some sense you clearly know that there is not halt decider because
there would be no need to re-define what the correct answer is if you
thought it were possible.
olcott <NoOne@nowhere.com> wrote:
On 3/19/2022 9:24 AM, Richard Damon wrote:
On 3/19/22 10:13 AM, olcott wrote:
[ .... ]
Since itself is not an actual input to itself this does not form a
contradictio
Except that the input IS a 'copy' of itself, and thus must behave
exactly like it. You don't seem to understand this property of Turing
Machine. If you wish to dispute it, find an actual counter example.
It can be empirically verified that the behavior of Ĥ applied to ⟨Ĥ⟩ is
not the same as the behavior of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
It can't be so verified without the code of H, which you refuse to
publish, and which you certainly haven't written. (If you had, you'd be
less bullish about its purported properties.)
[ .... ]
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
On 3/19/22 12:53 PM, olcott wrote:
On 3/19/2022 11:33 AM, Richard Damon wrote:
On 3/19/22 12:22 PM, Alan Mackenzie wrote:
olcott <NoOne@nowhere.com> wrote:
On 3/19/2022 9:24 AM, Richard Damon wrote:
On 3/19/22 10:13 AM, olcott wrote:
[ .... ]
It can't be so verified without the code of H, which you refuse toSince itself is not an actual input to itself this does not form a >>>>>>> contradictio
Except that the input IS a 'copy' of itself, and thus must behave
exactly like it. You don't seem to understand this property of Turing >>>>>> Machine. If you wish to dispute it, find an actual counter example.
It can be empirically verified that the behavior of Ĥ applied to
⟨Ĥ⟩ is
not the same as the behavior of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩. >>>>
publish, and which you certainly haven't written. (If you had,
you'd be
less bullish about its purported properties.)
[ .... ]
Actually, what he is missing is that they are supposed to be the
same, and as H/embedded_H needs to ALWAYS behave finitely, and go to
Qn only if H^ applied to <H^> will never halt.
No this is the moronic mistake of having a halt decider decide the
halt status of a non-input non-finite string and no decider can ever
do that.
Deciders ONLY compute the mapping from their input finite strings to
their own accept or reject state.
Just shows who is the moron.
The DEFINITION of a Halt Decider is that a Halt Decider applied to the
string <M> w needs to report on the behavior of M applied to w.
olcott <NoOne@nowhere.com> wrote:No one can possibly point out an error in these three points:
On 3/19/2022 12:55 PM, Alan Mackenzie wrote:
In comp.theory olcott <NoOne@nowhere.com> wrote:
On 3/19/2022 11:22 AM, Alan Mackenzie wrote:
olcott <NoOne@nowhere.com> wrote:
[ .... ]
It can be empirically verified that the behavior of Ĥ applied to ⟨Ĥ⟩ is
not the same as the behavior of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
It can't be so verified without the code of H, which you refuse to
publish, and which you certainly haven't written. (If you had, you'd be >>>>> less bullish about its purported properties.)
That we know that embedded_H is a simulating halt decider that aborts
its simulation and rejects its input as soon as it detects an infinitely >>>> repeating behavior pattern tells us that rejecting its input would be
correct on the basis of this infinitely repeating behavior pattern that >>>> we can see: (This by itself refutes Linz).
That is not "empirical verification". "Empirical verification" would be >>> running H on a Turing Machine and checking whether or not it has the
properties purported by you. We actually know, through mathematical
reasoning, that it does not.
Just as a matter of interest, your recent posts have been very
repetitive. You are not saying anything new. You are also not saying
anything correct. Now might be a very good time to cease posting on this >>> newsgroup, and devote your time and energies to something more
life-enhancing.
Like everyone else, I prove my point, ....
You fail to prove your point. What you call your "proofs" are not
logically sound.
.... you erase the part that proved my point and then claim that I did
not prove my point.
Richard and Ben (and one or two others) have pointed out the deficiencies
in what you call your proof, and done so very many times. You reply with abuse and insults, to a large extent. I've no desire to become a
recipient of such abuse.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 118:59:54 |
| Calls: | 6,662 |
| Files: | 12,210 |
| Messages: | 5,334,363 |