olcott <NoOne@NoWhere.com> writes:
While the input to H(P,P) is simulated in pure simulation mode it
cannot possibly ever reach a final state thus conclusively proving
that this input never halts.
Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
once claimed something "interesting" i.e. that you had
"encoded all of the ... Linz Turing machine H that correctly decides
halting for its fully encoded input pair: (Ĥ, Ĥ)"
and you insisted that
"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."
Does that "Linz Turing machine H" accept or reject the "fully encoded
input pair (H^, H^)", and what is the halting status if H^ when given H^ (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
then there was never anything interesting about what you were claiming,
but it was at least about Turing machines and the proof you have fixated
on.
But you also said your TMs H and H^ are "exactly and precisely as in
Linz", so really either
(1) H rejects (H^, H^) and H^ does not halt on input H^, or
(2) H accepts (H^, H^) and H^ halts on input H^
should be the case. So, come clean. Which was the case back then:
(1) H rejects (H^, H^) and H^ does not halt in input H^, or
(2) H accepts (H^, H^) and H^ halts on input H^, or
(3) H rejects (H^, H^) and H^ halts on input H^.
Without the comfort blanket of your huge pile of junk x86 code, I
suspect you won't dare say.
olcott <NoOne@NoWhere.com> writes:
Truism:
Every simulation that would never stop unless Halts() stops
it at some point specifies infinite execution.
Any algorithm that implements this truism is, of course, a halting
decider.
olcott <NoOne@NoWhere.com> writes:
(I answered your other belligerent reply before I read this.)
I would prefer to move away from division and animosity to achieve an
honest dialogue striving for mutual agreement, are you game?
Sure. Here are some other things about which I would like to seek
mutual agreement:
(1) A TM, M, halts on input s if the sequence of machine configurations
generated by M's state transition function, along with the input s,
is finite.
M is said to accept s if the final state is an accepting
state. Otherwise M is said to reject the input s.
(2) A halt decider is a TM, D, that accepts only and all inputs of theYes with André's definition of halting.
form <m,s> where m encodes a TM that halts on input s. D rejects
all others inputs.
(3) Did you have, back in Dec 2018, a Turing machine (as the term is
defined in any of the usual textbooks) that you called H to which
Linz's "hat" constriction could be applied to get another TM, H^?
(4) Using [X] to denote the string that encodes TM X, did your Dec 2018
H^ halt on input [H^]?
(5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
Either way you should post what you had in Dec 2018. Your conflicting
claims about what it was are one of the biggest obstacles to honest
dialogue. With what you had out in the open, we could get some
agreement on modified versions of (4) and (5).
olcott <NoOne@NoWhere.com> writes:
On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 7/28/2021 7:58 PM, Ben Bacarisse wrote:You don't want to answer the question it seems. OK.
olcott <NoOne@NoWhere.com> writes:
On 7/28/2021 6:22 PM, Ben Bacarisse wrote:Would you like to know what I was asking, or do you just want to keep >>>>> posting stuff for your entertainment? It's simpler for me if you are >>>>> not interested in knowing what I was asking, and I think it helps other >>>>> readers form an opinion as well.
olcott <NoOne@NoWhere.com> writes:
On 7/26/2021 6:48 PM, Ben Bacarisse wrote:If you didn't understand the question, I might be able to explain it >>>>>>> some other way. If you are just avoiding answering it, then just say so
olcott <NoOne@NoWhere.com> writes:
While the input to H(P,P) is simulated in pure simulation mode it >>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving >>>>>>>>>> that this input never halts.Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
once claimed something "interesting" i.e. that you had
"encoded all of the ... Linz Turing machine H that correctly decides
halting for its fully encoded input pair: (Ĥ, Ĥ)"
and you insisted that
"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."
Does that "Linz Turing machine H" accept or reject the "fully encoded >>>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
(encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^ >>>>>>>>> then there was never anything interesting about what you were claiming,
but it was at least about Turing machines and the proof you have fixated
on.
But you also said your TMs H and H^ are "exactly and precisely as in >>>>>>>>> Linz", so really either
(1) H rejects (H^, H^) and H^ does not halt on input H^, or >>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
should be the case. So, come clean. Which was the case back then: >>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or >>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
(3) H rejects (H^, H^) and H^ halts on input H^.
Without the comfort blanket of your huge pile of junk x86 code, I >>>>>>>>> suspect you won't dare say.
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
When we apply Ĥ to its own TM description ⟨Ĥ⟩
and I'll stop asking.
I totally ignored the convoluted mess of your question...
It was just another one of your endless dishonest dodges as can be
seen above This quote proves you are clueless: "H rejects (H^, H^)"
Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at >>>> some point.But you will answer part of it. You are saying that case (1) does not
apply.
None of the cases apply because you are not following the last step of
the proof where no H is involved.
Can we start talking about the last step of the actual proof?
I am trying to. The last step is what Ĥ(⟨Ĥ⟩) does:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ...
As you can see, that depends on the answer to my question. The configurations that follow that last ⊢* are those determined by what
that part of Ĥ that is identical to H does on input (⟨Ĥ⟩, ⟨Ĥ⟩).
So does the ... lead to Ĥ.qn or Ĥ.qy? If you don't like my wording
using H, does the part of Ĥ that is identical to H transition to Ĥ.qn
or Ĥ.qy?
olcott <NoOne@NoWhere.com> writes:
On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 7/28/2021 7:58 PM, Ben Bacarisse wrote:But you will answer part of it. You are saying that case (1) does not >>>>> apply.
olcott <NoOne@NoWhere.com> writes:
On 7/28/2021 6:22 PM, Ben Bacarisse wrote:Would you like to know what I was asking, or do you just want to keep >>>>>>> posting stuff for your entertainment? It's simpler for me if you are >>>>>>> not interested in knowing what I was asking, and I think it helps other >>>>>>> readers form an opinion as well.
olcott <NoOne@NoWhere.com> writes:
On 7/26/2021 6:48 PM, Ben Bacarisse wrote:If you didn't understand the question, I might be able to explain it >>>>>>>>> some other way. If you are just avoiding answering it, then just say so
olcott <NoOne@NoWhere.com> writes:
While the input to H(P,P) is simulated in pure simulation mode it >>>>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving >>>>>>>>>>>> that this input never halts.Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
once claimed something "interesting" i.e. that you had
"encoded all of the ... Linz Turing machine H that correctly decides
halting for its fully encoded input pair: (Ĥ, Ĥ)" >>>>>>>>>>> and you insisted that
"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."
Does that "Linz Turing machine H" accept or reject the "fully encoded
input pair (H^, H^)", and what is the halting status if H^ when given H^
(encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
then there was never anything interesting about what you were claiming,
but it was at least about Turing machines and the proof you have fixated
on.
But you also said your TMs H and H^ are "exactly and precisely as in
Linz", so really either
(1) H rejects (H^, H^) and H^ does not halt on input H^, or >>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
should be the case. So, come clean. Which was the case back then: >>>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or >>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or >>>>>>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^. >>>>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I >>>>>>>>>>> suspect you won't dare say.
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
When we apply Ĥ to its own TM description ⟨Ĥ⟩
and I'll stop asking.
I totally ignored the convoluted mess of your question...
It was just another one of your endless dishonest dodges as can be >>>>>> seen above This quote proves you are clueless: "H rejects (H^, H^)" >>>>> You don't want to answer the question it seems. OK.
Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
some point.
None of the cases apply because you are not following the last step of >>>> the proof where no H is involved.
Can we start talking about the last step of the actual proof?I am trying to. The last step is what Ĥ(⟨Ĥ⟩) does:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ...
As you can see, that depends on the answer to my question. The
configurations that follow that last ⊢* are those determined by what
that part of Ĥ that is identical to H does on input (⟨Ĥ⟩, ⟨Ĥ⟩). >>>
So does the ... lead to Ĥ.qn or Ĥ.qy? If you don't like my wording
using H, does the part of Ĥ that is identical to H transition to Ĥ.qn
or Ĥ.qy?
Ĥ( ⟨Ĥ⟩ ) specifies an infinite cycle from Ĥ.qx to Ĥ.q0 all the time >> that Ĥ.qx remains a pure simulator of its input.
Again, you state something trivial and avoid the question. As far as I
know, H is not a pure simulator (in your confusing wording it's a
simulator for a while and then it isn't).
This is the same criteria that both you and André agreed to:
Every simulation that would never stop unless its simulating halt
decider stops it at some point specifies infinite execution.
I retract all agreements you may think I've made. That's simpler than
trying to explain myself. If you claim, henceforth, that I agree with anything other than my own, or a published textbook definition of
halting, you will be arguing in bad faith.
Any chance you will now say if
Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult,
please ask for some help in understanding it.
olcott <NoOne@NoWhere.com> writes:
On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
(I answered your other belligerent reply before I read this.)
I would prefer to move away from division and animosity to achieve anSure. Here are some other things about which I would like to seek
honest dialogue striving for mutual agreement, are you game?
mutual agreement:
(1) A TM, M, halts on input s if the sequence of machine configurations
generated by M's state transition function, along with the input s, >>> is finite.
I like André's reaches one of its own finite states better.
Is this OK with you?
What you say here is too vague. If you can write it clearly and
formally, I'm sure we could agree on it, but I suspect you can't. In
the spirit of reaching an agreement, is there anything you object to in
my definition?
We can work on this.M is said to accept s if the final state is an acceptingYes
state. Otherwise M is said to reject the input s.
(2) A halt decider is a TM, D, that accepts only and all inputs of the
form <m,s> where m encodes a TM that halts on input s. D rejects
all others inputs.
Yes with André's definition of halting.
Is this OK with you?
Not unless you can write it clearly, no.
(3) Did you have, back in Dec 2018, a Turing machine (as the term is
defined in any of the usual textbooks) that you called H to which
Linz's "hat" constriction could be applied to get another TM, H^?
I never had a Turing machine.
OK, thanks. That's clear.
It was encoded in nearly complete C.
This raises lots of questions:
(3a) What are "the exact TMD instructions of the Linz Turing machine H"
that you had encoded by Dec 14th in relation to this C code?
(3b) What does "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 (Ĥ, Ĥ)" mean for C code?
Given that you had C code, the "UTM in C++" that you were writing that
would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C interpreter.
(3c) Did you really think you could write a C interpreter in "a week or
two"?
(3d) Why write an interpreter when C code is better compiled and a
debugger can then be used to give any required level of detail
about the execution?
In the spirit of mutual understanding, I hope you can see that these mysterious quotes will have led everyone away from the truth (that you
had C code) while re-forcing the mistaken impression that you had what
you had said you had: an actual Turing machine.
(4) Using [X] to denote the string that encodes TM X, did your Dec 2018
H^ halt on input [H^]?
(5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
Of course, if your answer to (3) is no, then (4) and (5) are irrelevant. >>> Either way you should post what you had in Dec 2018. Your conflicting
claims about what it was are one of the biggest obstacles to honest
dialogue. With what you had out in the open, we could get some
agreement on modified versions of (4) and (5).
These become
(4) Did your Dec 2018 C code for H^ halt on H^?
(5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
Dec 2018 code come to about "(Ĥ, Ĥ)"?
It is on a single piece of hand-written paper. I don't think that I
ever scanned it.
Unless you post it, we can't reach a mutual understanding about your
claim to have something that everyone else says is impossible. Maybe
you just had some C that does something entirely possible and
unsurprising. That is certainly the case now.
olcott <NoOne@NoWhere.com> writes:
On 7/30/2021 7:39 AM, Ben Bacarisse wrote:
Any chance you will now say if
Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult,
please ask for some help in understanding it.
Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn
An answer. Thank you.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause that applies to your H and Ĥ:
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me that it does. That is what this full (but abbreviated) state transition sequence means:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Which is it?
olcott <NoOne@NoWhere.com> writes:
On 7/30/2021 2:58 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 7/30/2021 7:39 AM, Ben Bacarisse wrote:
Any chance you will now say if
Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult, >>>>> please ask for some help in understanding it.
Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn
An answer. Thank you.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause >>> that applies to your H and Ĥ:
There is no H in the relevant last paragraph of the Linz proof that
forms the basis for the Linz conclusion.
Distraction. Everything you ignore below is about the proof and refers
only to Ĥ.
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me >>> that it does. That is what this full (but abbreviated) state transition >>> sequence means:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Which is it?
Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the
⟨Ĥ2⟩ copy then
Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the
⟨Ĥ3⟩ copy then
Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the
⟨Ĥ4⟩ copy then ...
This is an abuse of the notation (but I know what you mean). There is
no Ĥ1 or Ĥ2. If you think it helps to show which copy of ⟨Ĥ⟩ your simulating "decider" is either running and/or currently looking at, you
need to come up with a notation that does that.
At least I know what
this "math poem" means, because you've been saying this "it's a
simulator until" stuff for years.
The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩)
can't possibly ever reach its final state. Then it transitions to
Ĥ0.qn causing the outermost Ĥ0 to halt.
Apart from the bad notation, yes. All those copies and tests and
eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt
and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly >> ever reach its final state there is no contradiction or paradox and it
decided correctly.
You are free to define "decide correctly" in any way you like provided
you are honest about it. But you hooked people in by saying that your Ĥ
is "exactly and precisely as in Linz", and you quoted, even now, what
Linz has to say about such TMs:
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
This is your quote. You brought it up. You claimed your Ĥ was as Linz states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not halt. Linz makes no exceptions based on why the transitions from Ĥ.q0
wM to Ĥ.qn occur. Linz does not say
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt or if M applied wM only halts
because...
Are you now saying that your TM was not "as in Linz"? (You should,
because you've admitted that elsewhere.)
--------
You have real trouble with this notation so I don't think you will know
what I'm saying above, but for anyone else, here is a summary:
If we have a TM "as in Linz" then this applies:
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
When asked what Ĥ does when given ⟨Ĥ⟩ PO says that it (eventually) transitions to Ĥ.qn, so the above clause applies with M = Ĥ and wM = ⟨Ĥ⟩:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt
The first line says that Ĥ applied to ⟨Ĥ⟩ halts -- the final halting state is right there (Ĥ.qn) -- but the second line says that this should happen if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt. This is why PO's Ĥ is not "as in Linz".
On 31/07/2021 01:42, olcott wrote:
[...] At the end of 2018 I had only heard of TM complete and I knew
that this required unlimited memory.
Which every computer with the capability of reading from and
writing to a suitable external medium [eg USB stick, CD, floppy, mag
tape, paper tape or punched cards] and obeying a relatively small
program has. That's pretty-much everything that we would normally
have called a computer from the 1950s onwards.
[...]
C is equivalent to a TM for the subset of computations where it has
all the memory that it needs. I don't think that anyone else beside
me says this.
If you mean merely that C programs can be used to emulate a finite-state machine, then that has "always" been known, and I guess
that few research papers have thought it worth saying;
OTOH, it
would have been a normal thing to say for the past 40+ years when
explaining to students what a FSM is and giving examples. It would
also have been normal for the past 50+ years to explain that then-
current HLLs were overkill; you can build a UTM out of anything
that can do a few simple operations on [cf the above] an unbounded
storage medium. Everything else is an efficiency hack.
On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:
It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
behaviour "correct". You can call it anything you like. But it's not
"as in Linz". It does not say anything about Linz's proof. It does not
do anything people would call impossible or even interesting.
whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
theorems are refuted. Which you would expect. If results were consistent
it would have to be some cheap trick.
However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
nothing to do with the invert step of Linz' proof. This is maybe interesting, but in a small way, it's not a revolutionary result which will turn computer science upside down. But it's maybe worth mentioning.
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:
It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's >>> behaviour "correct". You can call it anything you like. But it's not
"as in Linz". It does not say anything about Linz's proof. It does not
do anything people would call impossible or even interesting.
whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
theorems are refuted. Which you would expect. If results were consistent
it would have to be some cheap trick.
I case there is some confusion, I mean that PO's Ĥ is not an Ĥ as
specified in Linz. Yes, everything is in accordance with the truth as
laid out in Linz and, indeed, in any textbook.
I point this out to PO because he brings it up. He keeps posting the specification of what an Ĥ, as Linz specifies it, would do:
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if (and only if) M applied to wM does not halt.
He claims (or used to claim) that his Ĥ meets this specification for at least the one case where wM == ⟨Ĥ⟩:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
To remain relevant, he /must/ keep insisting that his Ĥ meets the requirements laid out in Linz, if only for this one key input.
However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
nothing to do with the invert step of Linz' proof. This is maybe interesting,
but in a small way, it's not a revolutionary result which will turn computer >> science upside down. But it's maybe worth mentioning.
I don't follow. H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 making
that result the wrong one. If H(H_Hat, H_Hat) returned non-zero, H_Hat(H_Hat) would not halt, making that the wrong result. Whilst I
don't like this sort of language, H fails on H_Hat(H_Hat) precisely
because of how H_Hat is constructed from H.
On Sunday, 1 August 2021 at 16:30:46 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:Sure, there's a different proof, inspired by Linz's, but with the "invert
We've elimiated the "invert the result" step from Linz's proof. WeThe proof is still there, with all the same steps in it. I think you
have to insist that H is a "simulating halt decider" to achieve this.
mean there is a /different/ proof, without that step, that shows that
some naive "deciders" gets other cases wrong. I don't see why you find
that interesting, but I think that's the bottom line: you find some
things interesting that I don't.
the result" step removed. It only applies to naive simulating deciders.
So to make it into a proof of general interest, we've got to show that
a naive simulating decider can't be bettered by any other type of
decider.
Take its busy beaver score, for example. You might object that even a stepping scorer can't always detect when a machine won't halt. So just
But that seems to be a reasonable condition. We know there areAnd again I'm lost. Can you name an "interesting" property of a TM
many properties of Turing machines that cannot be determined other
than by stepping them.
computation that /can/ be determined by stepping it?
add a limit, which grows with then number of states to keep the set infinite. Busy beaver score before either a halt or m * N states steps.
Yes, that's a reasonable summary.
My guess (you'll have to confirm) is that you mean there are many
properties that we can't always determine by stepping, but stepping the
computation is the "best we can do". If so, we've had this discussion
before, and I still disagree.
olcott <NoOne@NoWhere.com> writes:
On 7/31/2021 5:08 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 7/30/2021 2:58 PM, Ben Bacarisse wrote:Distraction. Everything you ignore below is about the proof and refers
olcott <NoOne@NoWhere.com> writes:
On 7/30/2021 7:39 AM, Ben Bacarisse wrote:
Any chance you will now say if
Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult, >>>>>>> please ask for some help in understanding it.
Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn
An answer. Thank you.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause >>>>> that applies to your H and Ĥ:
There is no H in the relevant last paragraph of the Linz proof that
forms the basis for the Linz conclusion.
only to Ĥ.
This is an abuse of the notation (but I know what you mean). There isĤ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me
that it does. That is what this full (but abbreviated) state transition >>>>> sequence means:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Which is it?
Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the
⟨Ĥ2⟩ copy then
Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the
⟨Ĥ3⟩ copy then
Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the
⟨Ĥ4⟩ copy then ...
no Ĥ1 or Ĥ2. If you think it helps to show which copy of ⟨Ĥ⟩ your >>> simulating "decider" is either running and/or currently looking at, you
need to come up with a notation that does that.
A better notation is what I have in my PDF actual subscripts but
people here tel me that their newsreader makes sure to totally ignore
posts with HTML so that do even see the post at all.
I am happy you have a notation you like. Are you prepared to address
that fact that your H^ is not "as in Linz"?
At least I know what
this "math poem" means, because you've been saying this "it's a
simulator until" stuff for years.
The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩)Apart from the bad notation, yes. All those copies and tests and
can't possibly ever reach its final state. Then it transitions to
Ĥ0.qn causing the outermost Ĥ0 to halt.
eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Because the outermost Ĥ0.qx did not decide that Ĥ0 would never haltYou are free to define "decide correctly" in any way you like provided
and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly
ever reach its final state there is no contradiction or paradox and it >>>> decided correctly.
you are honest about it. But you hooked people in by saying that your Ĥ >>> is "exactly and precisely as in Linz", and you quoted, even now, what
Linz has to say about such TMs:
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
This is your quote. You brought it up. You claimed your Ĥ was as Linz >>> states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not >>> halt. Linz makes no exceptions based on why the transitions from Ĥ.q0
wM to Ĥ.qn occur. Linz does not say
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt or if M applied wM only halts
because...
Are you now saying that your TM was not "as in Linz"? (You should,
because you've admitted that elsewhere.)
Ĥ[0] is to be interpreted to mean Ĥ<sub>0</sub>
[0] Means the actual Turing machine and not a TM description.
[1] Means the first TM description parameter
[2] Means a copy of the the first TM description parameter
Now I am saying that when the actual unmodified Linz Ĥ is understood
to have a UTM/Halt-Decider at Ĥ[0].qx that this Ĥ[0].qx does correctly
decide that its input: (⟨Ĥ[1]⟩, ⟨Ĥ[2]⟩) can't possibly ever reach its
final state of Ĥ[1].qn or Ĥ[2].qn, therefore we know that its input
never halts therefore we know that a state transition from Ĥ[0].qx to
Ĥ0.qn is necessarily correct.
We all know you are declaring that to be correct. Here's why your Ĥ is
not "as in Linz". Linz requires that
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
if, and only if, the encoded M applied to wM does not halt. But you've
given us a case where your Ĥ is not like this:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's behaviour "correct". You can call it anything you like. But it's not
"as in Linz". It does not say anything about Linz's proof. It does not
do anything people would call impossible or even interesting.
Presumably, you will simply explain, yet again, why you choose to call
it correct. You might even, yet again, quote the symbols from Linz that don't apply to your Ĥ in order to make you posts seem relevant.
olcott <NoOne@NoWhere.com> writes:
On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
It matters not what I had.Because you can't justify it the honest debate you claim to want.
It only matters what I have.I.e. nothing of any interest. You make it plain in a previous reply
that you've had nothing of interest going right back to the original
deceptive claim.
If you are sincere about an honest dialogue then we must quit focusing >>>> on details of obsolete technology.And yet you skipped the big picture part:
(5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
Dec 2018 code come to about "(Ĥ, Ĥ)"?
The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
H(P,P)==0 now except that the never halting criteria is much more
elaborate. The initial criteria was very crude.
Ah, so you never had H and H_Hat that do anything that anyone would say
is impossible. Had you said, back in Dec 2018, "I have C code such that >>> H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
interested.
If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.
Ah, an honest dialogue requires me to ignore your past deception? Well,
I can accommodate that: you /currently/ don't have anything that anyone
would consider to be impossible or even interesting. An H/H_Hat pair
such that H(H_Hat, H_Hat) == 0 and H_Hat(H_Hat) halts is of no interest
to anyone. Is that better?
I think you owe everyone an apology. Even if there was no indent to
deceive, your words back then did everything possible to suggest some
impossible Turing machine. And you wouldn't say, until recently, even
when explicitly asked, what decision H came to. It was fishy from the
start.
You still owe everyone an apology. Neither Turing machines nor C code
are obsolete technology. If you really had what you falsely claimed to
have had, posting it at any time in the last 30 months would have
settled the matter. It still would, but you either never had anything
at all or you are too embarrassed to post what it was.
olcott <NoOne@NoWhere.com> writes:
On 8/1/2021 5:39 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
It matters not what I had.Because you can't justify it the honest debate you claim to want.
It only matters what I have.I.e. nothing of any interest. You make it plain in a previous reply >>>>> that you've had nothing of interest going right back to the original >>>>> deceptive claim.
If you are sincere about an honest dialogue then we must quit focusing >>>>>> on details of obsolete technology.And yet you skipped the big picture part:
(5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
Dec 2018 code come to about "(Ĥ, Ĥ)"?
The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that >>>>>> H(P,P)==0 now except that the never halting criteria is much more
elaborate. The initial criteria was very crude.
Ah, so you never had H and H_Hat that do anything that anyone would say >>>>> is impossible. Had you said, back in Dec 2018, "I have C code such that >>>>> H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
interested.
If you are sincere about an honest dialogue then we must quit focusing >>>> on details of obsolete technology.
Ah, an honest dialogue requires me to ignore your past deception? Well, >>> I can accommodate that: you /currently/ don't have anything that anyone
would consider to be impossible or even interesting. An H/H_Hat pair
such that H(H_Hat, H_Hat) == 0 and H_Hat(H_Hat) halts is of no interest
to anyone. Is that better?
When H is a simulating partial halt decider and the halt decider
embedded in Ĥ at Ĥ.qx is a simulating halt decider then:
It is the case that the input to H(P,P) and the input to Ĥ(⟨Ĥ⟩) cannot >> possibly ever reach their final state and must have their simulation
aborted to prevent the infinite execution of P and Ĥ.
Let's have an honest dialogue about that.
Yes, let's. Here's how to say what happens without all those vague
(and, frankly, incorrect) words:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If you don't mean
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
can you say what you do mean formally? Formally means using some
formal notation like Linz does.
If what you want to say is all about what happens in that second ⊢*
(i.e. all the nested simulations and so on) then don't bother, because
what makes your Ĥ irrelevant is what state Ĥ applied to ⟨Ĥ⟩ gets to, not
how it gets there.
You still owe everyone an apology. Neither Turing machines nor C codeI think you owe everyone an apology. Even if there was no indent to >>>>> deceive, your words back then did everything possible to suggest some >>>>> impossible Turing machine. And you wouldn't say, until recently, even >>>>> when explicitly asked, what decision H came to. It was fishy from the >>>>> start.
are obsolete technology. If you really had what you falsely claimed to
have had, posting it at any time in the last 30 months would have
settled the matter. It still would, but you either never had anything
at all or you are too embarrassed to post what it was.
The technology that I had in 2018 is obsolete and not relevant to an
honest dialogue about the technology that I currently have.
You had C code. C code is not obsolete. It's also a good formalism.
You could say what you meant back then by posting the code. But you
won't post it either because you never had it or you are embarrassed by
it. An honest academic would simply say "this is what I had -- very
rough and ready, isn't it? Here's the tidied up version...".
On 8/2/2021 11:31 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 8/1/2021 5:39 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
It matters not what I had.Because you can't justify it the honest debate you claim to want.
It only matters what I have.I.e. nothing of any interest. You make it plain in a previous reply >>>>>> that you've had nothing of interest going right back to the original >>>>>> deceptive claim.
If you are sincere about an honest dialogue then we must quitAnd yet you skipped the big picture part:
focusing
on details of obsolete technology.
(5) You said you had "an H that decides (Ĥ, Ĥ)". What decision >>>>>>>> did your
Dec 2018 code come to about "(Ĥ, Ĥ)"?
The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that >>>>>>> H(P,P)==0 now except that the never halting criteria is much more >>>>>>> elaborate. The initial criteria was very crude.
Ah, so you never had H and H_Hat that do anything that anyone
would say
is impossible. Had you said, back in Dec 2018, "I have C code
such that
H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been >>>>>> interested.
If you are sincere about an honest dialogue then we must quit focusing >>>>> on details of obsolete technology.
Ah, an honest dialogue requires me to ignore your past deception?
Well,
I can accommodate that: you /currently/ don't have anything that anyone >>>> would consider to be impossible or even interesting. An H/H_Hat pair >>>> such that H(H_Hat, H_Hat) == 0 and H_Hat(H_Hat) halts is of no interest >>>> to anyone. Is that better?
When H is a simulating partial halt decider and the halt decider
embedded in Ĥ at Ĥ.qx is a simulating halt decider then:
It is the case that the input to H(P,P) and the input to Ĥ(⟨Ĥ⟩) cannot
possibly ever reach their final state and must have their simulation
aborted to prevent the infinite execution of P and Ĥ.
Let's have an honest dialogue about that.
Yes, let's. Here's how to say what happens without all those vague
(and, frankly, incorrect) words:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If you don't mean
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
can you say what you do mean formally? Formally means using some
formal notation like Linz does.
As Linz already specifies yet does not encode in his notation there are
at least three separate and distinct instances of Ĥ.
The first one of these instances is the actual Turing machine Ĥ.
The second one is the TM description ⟨Ĥ⟩ input to Ĥ.
The third one is the copy of the TM description ⟨Ĥ⟩ input to Ĥ.
If we do not keep track of these distinctions then it seems like Ĥ.qx decides that its input never halts and then its input immediately halts.
This would be an actual contradiction.
When we do keep track of these distinctions then the input: ⟨Ĥ^1⟩ to Ĥ^0
can be understood to never reach its final states Ĥ^1.qy or Ĥ^1.qn thus proving that Ĥ^0.qx did correctly decide that its input ⟨Ĥ^1⟩ ⟨Ĥ^2⟩
never halts.
If what you want to say is all about what happens in that second ⊢*
(i.e. all the nested simulations and so on) then don't bother, because
what makes your Ĥ irrelevant is what state Ĥ applied to ⟨Ĥ⟩ gets to, not
how it gets there.
You still owe everyone an apology. Neither Turing machines nor C code >>>> are obsolete technology. If you really had what you falsely claimed to >>>> have had, posting it at any time in the last 30 months would haveI think you owe everyone an apology. Even if there was no indent to >>>>>> deceive, your words back then did everything possible to suggest some >>>>>> impossible Turing machine. And you wouldn't say, until recently, >>>>>> even
when explicitly asked, what decision H came to. It was fishy from >>>>>> the
start.
settled the matter. It still would, but you either never had anything >>>> at all or you are too embarrassed to post what it was.
The technology that I had in 2018 is obsolete and not relevant to an
honest dialogue about the technology that I currently have.
You had C code. C code is not obsolete. It's also a good formalism.
You could say what you meant back then by posting the code. But you
won't post it either because you never had it or you are embarrassed by
it. An honest academic would simply say "this is what I had -- very
rough and ready, isn't it? Here's the tidied up version...".
olcott <NoOne@NoWhere.com> writes:
On 8/1/2021 5:54 AM, Ben Bacarisse wrote:
I am happy you have a notation you like. Are you prepared to address
that fact that your H^ is not "as in Linz"?
My Ĥ is exactly the Linz Ĥ with the additional elaboration that the
second wildcard state transition ⊢* is defined to be a simulating halt
decider.
No. I've explained many times now why your Ĥ is not at all "the Linz
Ĥ". Do you see any point in my doing so again?
We all know you are declaring that to be correct. Here's why your Ĥ is >>> not "as in Linz". Linz requires that
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
if, and only if, the encoded M applied to wM does not halt. But you've
given us a case where your Ĥ is not like this:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
And when we eliminate the fallacy of equivocation error we have
Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn
The only thing I think you are equivocating on is pretending that Ĥ[0]
is not Ĥ, and it doesn't look as if you've removed that error. I think
you /should/ remove it so that you can be saying something of value
about Ĥ.
The way that you do it when your twin bother commits a crime that
makes you guilty.
Ĥ[0].q0 ⟨Ĥ[1]⟩ only halts because the simulation of the
the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ was aborted.
(a) The simulation of the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩
was aborted because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could
ever possibly reach their final states.
(b) Because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could ever possibly reach
their final states we know that they never halt.
(c) Because they never halt we know that Ĥ[0].qx correctly decided
that its input never halts.
This is the same as: X > Y & Y > Z therefore X > Z
I do seem to have a correct chain of inference.
I do not think that you can point to any error in
this chain of inference.
In an honest dialogue when you would disagree that a
chain of inference derives a correct conclusion you
would point to a specific error in this chain of inference.
What is the error in (a)(b)(c) ?
Far too many to go into all of them (if you are not inclined to correct anything, just jump to number 7) but ere are some:
(1) Unless Ĥ[0] is just another name for Ĥ you are not saying anything I
care about. What matters is what Ĥ applied to ⟨Ĥ⟩ does.
(2) TMs don't "abort". The sequence of configurations ends.
(3) Stop talking about what "could possibly" happen. TMs do what they
do. There are no "possibilities".
(4) ⟨Ĥ[1]⟩ and ⟨Ĥ[2]⟩ are strings. A string does not "reach" anything.
Strings don't even have states that can be reached. I can unravel
this, but why must your readers work hard to unpick your metaphors?
(5) Ĥ[0].qx is a state. It does not decide anything. (Again, I can
guess what you mean but you asked for help.)
(6) States don't have input. Whilst I could guess that you mean "the
tape" at the point the state is entered", states in a TM may be
entered many times so there is no obvious single "input".
(7) The correct behaviour of Ĥ is not based on (a) and (b) but on what
Linz says about Ĥ applied to ⟨Ĥ⟩. Your Ĥ does not behave as Linz's
Ĥ should, even in the one case you care about.
olcott <NoOne@NoWhere.com> writes:
On 8/2/2021 2:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 8/1/2021 5:54 AM, Ben Bacarisse wrote:No. I've explained many times now why your Ĥ is not at all "the Linz
I am happy you have a notation you like. Are you prepared to address >>>>> that fact that your H^ is not "as in Linz"?
My Ĥ is exactly the Linz Ĥ with the additional elaboration that the
second wildcard state transition ⊢* is defined to be a simulating halt >>>> decider.
Ĥ". Do you see any point in my doing so again?
I suspect not. You certainly have not asked a single question that
could help you to understand why your Ĥ is irrelevant.
The only thing I think you are equivocating on is pretending that Ĥ[0]We all know you are declaring that to be correct. Here's why your Ĥ is >>>>> not "as in Linz". Linz requires that
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
if, and only if, the encoded M applied to wM does not halt. But you've >>>>> given us a case where your Ĥ is not like this:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
And when we eliminate the fallacy of equivocation error we have
Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn
is not Ĥ, and it doesn't look as if you've removed that error. I think >>> you /should/ remove it so that you can be saying something of value
about Ĥ.
It is clear from the text that Linz does specify at least three
different instances of Ĥ, The TM the TMD input ⟨Ĥ⟩ and a copy of this >> TMD input.
Still equivocating. Either Ĥ[0] = Ĥ or you are wasting everyone's time.
(This is mathematical equality. Ĥ is a tuple of sets. If Ĥ[0] is not exactly identical in every way to Ĥ then I don't care about it. Note
that I'm not disputing your right, for ease of explanation, to give
identical things more than one name. But the same permission allows me
to use any of the names because they name the same thing.)
You are wrong because
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
where Linz requires that
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
Either you ask questions that might help you to understand what I'm
saying, or you can just repeat again, in ever greater detail, what
happens in that ⊢* as if the exact way in which you are wrong is the key thing you want to tell the world. It's up to you.
Please don't think I don't know what you are saying. I understand all
the copying and levels and so on. But the details don't make you right because it's the outcome that makes you wrong. No explanation of how
you get the wrong behaviour, no matter how detailed, makes the wrong behaviour right. Your Ĥ is just one of countless other TMs that do not
do what Linz says is impossible, even for this one input.
I'll leave it there. If you really want my comments on your replies to
the errors you asked me to point it, I'll post again, but it it's all
noise compared to the big mistake.
olcott <NoOne@NoWhere.com> writes:
On 8/2/2021 7:11 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
(I'm going to ignore errors that I've already pointed out.)
If you really do sincerely want an actual honest dialogue you would
carefully work through all the steps to confirm that the input ⟨Ĥ⟩ ⟨Ĥ⟩
to Ĥ.qx never halts.
If you want me to comment on that, write it without the errors. It has
two, both of which I've commented on before. If you are sincere, you
will want to write clearly and without errors.
Once we have mutual agreement that Ĥ.qx correctly decides that its
input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts and Ĥ does halt, then we have the basis to
go to the next step and resolve the actual paradox.
There is no paradox. That Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn when Ĥ applied to ⟨Ĥ⟩
clearly halts is not paradoxical. It's just not the sort of TM the
proof is talking about. And how could it be? The "Linz Ĥ" is as
illogical as a cat that is a dog.
As long as it is simply dismissed out-of-hand as a contradiction the
paradox remains unresolved.
There is no contradiction or paradox. You Ĥ is just the wrong sort of
TM. The proof you want to "refute" is talking about this sort of Ĥ:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
On Tuesday, 3 August 2021 at 02:01:14 UTC+1, olcott wrote:
On 8/2/2021 7:20 PM, Ben Bacarisse wrote:With your H, H_Hat <H_Hat> halts. That's common ground.
As long as you keep thinking of it as a resolved contradiction the
actual paradox remains unresolved.
I proved that Ĥ.qx does correctly decide that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts it is also equally proven that Ĥ halts thus a paradox and not a
contradiction is formed.
My current answer to this is GIGO self-contradictory input <IN>
contractory output <OUT>. There may be a better answer.
With your H H<H_Hat><H_Hat> returns false (non-halting). That's also
common ground.
So one positive in this is that you are clearly being honest about the behaviour of your code.
But don't you see that this behaviour is exactly what Linz says would
happen? H_Hat<H_Hat> is a case that H cannot classify correctly.
You're trying to claim that H_Hat<H_Hat> doens't really halt because
the recursion of H instances is terminated by H.
This leads us down
a rabbit hole of talking of the "inner" and "outer" H or H1, H2 and so on.
But what Linz is saying is that the internal details of H don't matter. It can be a simulating halt decider, a control graph anlyser, or even just
a stub machine that returns a flag. However cleverly or simply it is
written, it classifies H_Hat<H_Hat> wrongly.
I think it's high time to wind up these threads.
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
On 8/3/2021 12:29 AM, Malcolm McLean wrote:We agree that P(P) halts.
No I have never been saying that. I am claiming that the input to H(P,P)
You're trying to claim that H_Hat<H_Hat> doens't really halt because
the recursion of H instances is terminated by H.
never halts whether or not H terminates its simulation of this input.
So now you're drawing a distinction between P(P) and "the input to H(P,P)". ThIs is nonsense..
You can't complain about lack of attention.We can see that the input to H(P,P) never halts therefore H IS NOT WRONG. >>> I think it's high time to wind up these threads.
I think that it is high time that people actually pay complete attention.
On 2021-08-03 09:21, olcott wrote:
On 8/3/2021 9:33 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
On 8/3/2021 12:29 AM, Malcolm McLean wrote:We agree that P(P) halts.
No I have never been saying that. I am claiming that the input to
You're trying to claim that H_Hat<H_Hat> doens't really halt because >>>>> the recursion of H instances is terminated by H.
H(P,P)
never halts whether or not H terminates its simulation of this input.
So now you're drawing a distinction between P(P) and "the input to
H(P,P)".
ThIs is nonsense..
Try and find any error in (a)(b)(c)(d) on page 6
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The error, which has been pointed out repeatedly, is in your (b).
You claim "there are no control flow instructions in the execution trace
that would escape the infinite recursion", but there *are* flow control instructions. But your trace is incomplete and skips over the call to
B82 where these flow control instructions reside.
The code at B82 is *part* of the computation performed by P. It *must*
be included in any trace of P which purports to be a complete and honest trace.
You don't seem to grasp the fact that *all* code executed by a
particular computation from the moment the computation begins to the
time it halts (assuming it halts) is part of that computation. It
doesn't matter whether the code in question is shared by some other
routine, or is operating system code or whatever. These are purely
artificial distinctions which play no role in the theory of computation.
André
On 2021-08-03 14:47, olcott wrote:
On 8/3/2021 3:08 PM, André G. Isaak wrote:
On 2021-08-03 13:26, olcott wrote:
On 8/3/2021 12:11 PM, André G. Isaak wrote:
On 2021-08-03 09:21, olcott wrote:
On 8/3/2021 9:33 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
On 8/3/2021 12:29 AM, Malcolm McLean wrote:We agree that P(P) halts.
No I have never been saying that. I am claiming that the input >>>>>>>> to H(P,P)
You're trying to claim that H_Hat<H_Hat> doens't really halt >>>>>>>>> because
the recursion of H instances is terminated by H.
never halts whether or not H terminates its simulation of this >>>>>>>> input.
So now you're drawing a distinction between P(P) and "the input
to H(P,P)".
ThIs is nonsense..
Try and find any error in (a)(b)(c)(d) on page 6
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The error, which has been pointed out repeatedly, is in your (b).
You claim "there are no control flow instructions in the execution
trace that would escape the infinite recursion", but there *are*
flow control instructions. But your trace is incomplete and skips
over the call to B82 where these flow control instructions reside.
Whether H aborts its simulation of P or not P never reaches its
final state.
But H's simulation of P is *not* a computation.
Sure it is.
The pure simulation of a computation on its input is computationally
equivalent to the direct execution of this same computation on its input.
No. It isn't. A computation is a free-standing, self-contained piece of
code. When you run H(P, P) the computation P(P) isn't being computed.
It's being evaluated. H(P, P) is the only computation being run in this
case.
And your H *doesn't* perform a pure simulation of its input, so we can't
even talk about the simulation as being 'computationally equivalent' to
some computation.
When we run H(P, P) the only computation being performed is H(P, P),
and if H aborts its simulation of P(P), then control returns to H
which then Halts.
The job of a halt decider is to correctly predict the future behavior
of its input. Because the input to H(P,P) does not transition to its
final state whether or not H aborts the simulation of this input we
know that this input never halts.
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and
an input, whether the program will finish running, or continue to run
forever. https://en.wikipedia.org/wiki/Halting_problem
Because the P that halts is not: "a description of an arbitrary
computer program" it is not in the scope of the Halting Problem. Only
the input to P is in scope of the halting problem.
Here you're very confused. The "P that halts" *is* the computation which
the input to H describes. A halt decider takes a description of an
arbitrary program and answers *about the program described by that description*. The "input to P" isn't a computation. It's a description
of a computation. Halting applies to actual computations, not to descriptions.
André
On 2021-08-03 13:26, olcott wrote:
On 8/3/2021 12:11 PM, André G. Isaak wrote:
On 2021-08-03 09:21, olcott wrote:
On 8/3/2021 9:33 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
On 8/3/2021 12:29 AM, Malcolm McLean wrote:We agree that P(P) halts.
No I have never been saying that. I am claiming that the input to
You're trying to claim that H_Hat<H_Hat> doens't really halt because >>>>>>> the recursion of H instances is terminated by H.
H(P,P)
never halts whether or not H terminates its simulation of this input. >>>>>>
So now you're drawing a distinction between P(P) and "the input to
H(P,P)".
ThIs is nonsense..
Try and find any error in (a)(b)(c)(d) on page 6
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The error, which has been pointed out repeatedly, is in your (b).
You claim "there are no control flow instructions in the execution
trace that would escape the infinite recursion", but there *are* flow
control instructions. But your trace is incomplete and skips over the
call to B82 where these flow control instructions reside.
Whether H aborts its simulation of P or not P never reaches its final
state.
But H's simulation of P is *not* a computation.
When we run H(P, P) the only computation being performed is H(P, P), and
if H aborts its simulation of P(P), then control returns to H which then Halts.
When we run P(P) as a computation, again, the only computation being performed is P(P). Any simulations performed by P are *not*
computations, and when some simulation is aborted control returns to the outermost P which then halts. And the behaviour of the actual
independent computation P determines the *only* correct answer to the question 'does P(P) halt?'.
The question which H(P, P) is supposed to answer *isn't* about some
internal simulation. It's supposed to answer a question about an actual computation, P(P) and we know that that computation halts. What occurs
in some internal simulation isn't relevant to the answer to this question.
The conditional instructions are merely the aspect of H aborting its
simulation of P.
Which then allows the *actual* computation being performed to halt. The halting problem is *only* concerned with actual computations.
Because P never reaches its final state whether H aborts its
simulation of P or not we know that P never halts.
Again, the question being asked isn't concerned with the simulation but
with the actual computation. The simulation is *part* of that
computation. The fact that the simulation gets aborted is *also* part of
the computation, and that allows the *whole* computation to halt. The
halting problem isn't interested in some part of a computation, only the computation as a whole.
The code at B82 is *part* of the computation performed by P. It
*must* be included in any trace of P which purports to be a complete
and honest trace.
Again, if you stopped omitting a portion of your traces, things would be clearer to you.
Remember that the halting problem is concerned with computations, not
with subroutines. Since you insist on using C rather than actual Turing Machines, though, this minimally requires that your H and your P be *separate* programs. That means each one should have its own source file
with its own main. Each should be compiled and linked separately. Your insistence on sticking everything into a single source file is a cheat
which you need to abandon.
H needs to take as input a complete *program*, not just some function
which is part of the same source file as H.
André
On 2021-08-03 15:03, olcott wrote:
On 8/3/2021 3:56 PM, André G. Isaak wrote:
On 2021-08-03 14:47, olcott wrote:
On 8/3/2021 3:08 PM, André G. Isaak wrote:
On 2021-08-03 13:26, olcott wrote:
On 8/3/2021 12:11 PM, André G. Isaak wrote:
On 2021-08-03 09:21, olcott wrote:
On 8/3/2021 9:33 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
On 8/3/2021 12:29 AM, Malcolm McLean wrote:We agree that P(P) halts.
No I have never been saying that. I am claiming that the input >>>>>>>>>> to H(P,P)
You're trying to claim that H_Hat<H_Hat> doens't really halt >>>>>>>>>>> because
the recursion of H instances is terminated by H.
never halts whether or not H terminates its simulation of this >>>>>>>>>> input.
So now you're drawing a distinction between P(P) and "the input >>>>>>>>> to H(P,P)".
ThIs is nonsense..
Try and find any error in (a)(b)(c)(d) on page 6
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The error, which has been pointed out repeatedly, is in your (b). >>>>>>>
You claim "there are no control flow instructions in the
execution trace that would escape the infinite recursion", but
there *are* flow control instructions. But your trace is
incomplete and skips over the call to B82 where these flow
control instructions reside.
Whether H aborts its simulation of P or not P never reaches its
final state.
But H's simulation of P is *not* a computation.
Sure it is.
The pure simulation of a computation on its input is computationally
equivalent to the direct execution of this same computation on its
input.
No. It isn't. A computation is a free-standing, self-contained piece
of code. When you run H(P, P) the computation P(P) isn't being
computed. It's being evaluated. H(P, P) is the only computation being
run in this case.
So you don't understand how UTMs work.
I'm well aware of how UTMs work. I am also aware that an x86 simulator
is not the same thing as a UTM.
And your H *doesn't* perform a pure simulation of its input, so we
can't even talk about the simulation as being 'computationally
equivalent' to some computation.
The fact that the first seven instructions of P keep repeating while H
is in pure simulation mode proves that H is doing pure simulation mode
correctly.
The problem is that your 'pure simulation mode' is a cheat.
Your H and P *need* to be independent, self-contained programs. They
need to both be compiled and linked separately resulting in two
different executables. This means that the copy of H contained in P will
be *distinct* from program H. It will be at an entirely different
address and any code inside H which tells it to ignore its 'own code'
will not result in it ignoring the H contained in P.
That also means that any change in the "mode" in which the main H runs *cannot* have any effect on what the H contained in P does.
Your 'pure simulation mode' is only valid as a test if it applies *only*
to the behaviour of H, and not to the behaviour of the H contained
inside P.
If you change what the H inside P does, you are then talking about an *entirely different* computation which has no bearing on the halting behaviour of P.
You can't evaluate whether P halts by considering what some modified
version of P does, which is in effect what you are doing.
André
On 2021-08-03 15:50, olcott wrote:
On 8/3/2021 4:26 PM, André G. Isaak wrote:
On 2021-08-03 15:03, olcott wrote:
On 8/3/2021 3:56 PM, André G. Isaak wrote:
On 2021-08-03 14:47, olcott wrote:
On 8/3/2021 3:08 PM, André G. Isaak wrote:
On 2021-08-03 13:26, olcott wrote:
On 8/3/2021 12:11 PM, André G. Isaak wrote:
On 2021-08-03 09:21, olcott wrote:
On 8/3/2021 9:33 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote: >>>>>>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
We agree that P(P) halts.No I have never been saying that. I am claiming that the >>>>>>>>>>>> input to H(P,P)
You're trying to claim that H_Hat<H_Hat> doens't really >>>>>>>>>>>>> halt because
the recursion of H instances is terminated by H.
never halts whether or not H terminates its simulation of >>>>>>>>>>>> this input.
So now you're drawing a distinction between P(P) and "the >>>>>>>>>>> input to H(P,P)".
ThIs is nonsense..
Try and find any error in (a)(b)(c)(d) on page 6
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The error, which has been pointed out repeatedly, is in your (b). >>>>>>>>>
You claim "there are no control flow instructions in the
execution trace that would escape the infinite recursion", but >>>>>>>>> there *are* flow control instructions. But your trace is
incomplete and skips over the call to B82 where these flow
control instructions reside.
Whether H aborts its simulation of P or not P never reaches its >>>>>>>> final state.
But H's simulation of P is *not* a computation.
Sure it is.
The pure simulation of a computation on its input is
computationally equivalent to the direct execution of this same
computation on its input.
No. It isn't. A computation is a free-standing, self-contained
piece of code. When you run H(P, P) the computation P(P) isn't
being computed. It's being evaluated. H(P, P) is the only
computation being run in this case.
So you don't understand how UTMs work.
I'm well aware of how UTMs work. I am also aware that an x86
simulator is not the same thing as a UTM.
It is equivalent. In any case my exactly same reasoning directly
applies to the Linz proof.
No, it isn't equivalent. A UTM takes a description of a *Turing Machine*
as its input. A description of an x86 program is not a Turing Machine.
How can two computations which take entirely distinct inputs be equivalent?
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
When Ĥ is applied to its own Turing Machine description ⟨Ĥ⟩ the
embedded halt decider at Ĥ.qx correctly decides that its input ⟨Ĥ⟩ ⟨Ĥ⟩
never halts.
Inputs neither halt nor don't halt. Only computations halt. >
And Ĥ.qx isn't an 'embedded halt decider'. It is a state.
And your H *doesn't* perform a pure simulation of its input, so we
can't even talk about the simulation as being 'computationally
equivalent' to some computation.
The fact that the first seven instructions of P keep repeating while
H is in pure simulation mode proves that H is doing pure simulation
mode correctly.
The problem is that your 'pure simulation mode' is a cheat.
That the execution trace of the simulation of P precisely corresponds
to its source-code proves beyond all possible doubt that the pure
simulation of P by H is correct. There is no way to wiggle out of this.
No. It doesn't 'precisely correspond' to its source code because your
trace *omits* a big chunk of code.
Your H and P *need* to be independent, self-contained programs. They
need to both be compiled and linked separately resulting in two
different executables. This means that the copy of H contained in P
will be *distinct* from program H. It will be at an entirely
different address and any code inside H which tells it to ignore its
'own code' will not result in it ignoring the H contained in P.
That also means that any change in the "mode" in which the main H
runs *cannot* have any effect on what the H contained in P does.
Your 'pure simulation mode' is only valid as a test if it applies
*only* to the behaviour of H, and not to the behaviour of the H
contained inside P.
If you change what the H inside P does, you are then talking about an
*entirely different* computation which has no bearing on the halting
behaviour of P.
You can't evaluate whether P halts by considering what some modified
version of P does, which is in effect what you are doing.
André
That the execution trace of the simulation of P precisely corresponds
to its source-code proves beyond all possible doubt that the pure
simulation of P by H is correct. There is no way to wiggle out of this.
No. It doesn't 'precisely correspond' to its source code because your
trace *omits* a big chunk of code.
Come back and post a complete trace once you've actually set up your H
and P *properly*. i.e. as two *separate* programs which have been
compiled and linked two form two separate, *complete* executables where
P does not call any code contained in H. If there is code in common, it
must be *duplicated* so that each executable contains its own copy of
this code.
There is no point discussing your implementation where your H and P are contained in a single executable. That's not how 'TM equivalents' work,
nor is it how the Linz Proof constructs H_Hat, and no conclusions which
you draw from such a mangled implementation can possibly shed any light
on the halting problem.
If you don't grasp why what you are doing is illegitimate, then I
suggest you go and actually learn what the term 'computation' means.
That would involve actually reading Linz and/or Sipser *from the
beginning*. Your notion than you can somehow overcome a well-established proof without even grasping the fundamentals of the subject matter is mystifying to say the least.
André
olcott <NoOne@NoWhere.com> writes:
On 8/2/2021 2:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 8/1/2021 5:54 AM, Ben Bacarisse wrote:No. I've explained many times now why your Ĥ is not at all "the Linz
I am happy you have a notation you like. Are you prepared to address >>>>> that fact that your H^ is not "as in Linz"?
My Ĥ is exactly the Linz Ĥ with the additional elaboration that the
second wildcard state transition ⊢* is defined to be a simulating halt >>>> decider.
Ĥ". Do you see any point in my doing so again?
I suspect not. You certainly have not asked a single question that
could help you to understand why your Ĥ is irrelevant.
The only thing I think you are equivocating on is pretending that Ĥ[0]We all know you are declaring that to be correct. Here's why your Ĥ is >>>>> not "as in Linz". Linz requires that
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
if, and only if, the encoded M applied to wM does not halt. But you've >>>>> given us a case where your Ĥ is not like this:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
And when we eliminate the fallacy of equivocation error we have
Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn
is not Ĥ, and it doesn't look as if you've removed that error. I think >>> you /should/ remove it so that you can be saying something of value
about Ĥ.
It is clear from the text that Linz does specify at least three
different instances of Ĥ, The TM the TMD input ⟨Ĥ⟩ and a copy of this >> TMD input.
Still equivocating. Either Ĥ[0] = Ĥ or you are wasting everyone's time.
(This is mathematical equality. Ĥ is a tuple of sets. If Ĥ[0] is not exactly identical in every way to Ĥ then I don't care about it. Note
that I'm not disputing your right, for ease of explanation, to give
identical things more than one name. But the same permission allows me
to use any of the names because they name the same thing.)
You are wrong because
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
where Linz requires that
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
On Wednesday, 4 August 2021 at 05:55:59 UTC+1, olcott wrote:
We agree that P(P) halts and that H(P, P) reports false (non-halting).
I am not willing to talk about anything besides page 6 until we have
mutual agreement on page 6.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
I've suggested that maybe you are trying to argue that P(P)'s halting
doesn't count, because it is generated by the copy of H inside P.
You've rejected that idea, and insist that H(P,P) has correctly determined
that P(P) is non-halting.
I don't really think there's anything useful left to say.
On 2021-08-03 22:55, olcott wrote:
On 8/3/2021 11:38 PM, olcott wrote:
On 8/3/2021 11:36 PM, André G. Isaak wrote:
On 2021-08-03 22:25, olcott wrote:
On 8/3/2021 11:16 PM, André G. Isaak wrote:
On 2021-08-03 22:00, olcott wrote:
On 8/3/2021 10:56 PM, André G. Isaak wrote:
On 2021-08-03 21:23, olcott wrote:
The key point is that only the input to the halt decider is
within the scope of the halting problem.
As long as the halt decider correctly decides its input what >>>>>>>>> these same programs do what they are not inputs to the halt
decider make no difference to the actual halting problem.
You have this completely back-assward.
How the TM described by the input to a halt decider behaves when >>>>>>>> they are run as *independent* computations (i.e. not as inputs >>>>>>>> to the halt decider) is the question a halt decider is supposed >>>>>>>> to answer by the very definition of a 'halt decider'. If the
answer provided by the decider does not match the behavior of
the *independent* computation, then that answer is wrong.
Talking about how the description behaves "as an input" isn't
even coherent. Inputs don't behave like anything. They are just >>>>>>>> data.
André
In computability theory, the halting problem is the
problem of determining,
from a description of an arbitrary computer program and an input, >>>>>>> from a description of an arbitrary computer program and an input, >>>>>>> from a description of an arbitrary computer program and an input, >>>>>>> from a description of an arbitrary computer program and an input, >>>>>>>
whether the program will
finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
I have proved that the input to H(P,P) never halts whether or not >>>>>>> it is aborted by H, are you going to have an honest dialogue
about the steps of the proof or not?
Yes, and when run H(P, P) the arbitrary program and input which it >>>>>> is being given described P(P).
It is supposed to answer how that *program* will behave. And you
have acknowledged that that program *halts*. That behaviour is
what *defines* the correct answer to the question 'does P(P)
halt'. And your H gets this *wrong*.
The halting question is not concerned with how the input string
behaves inside your partial simulator. It is *only* concerned with >>>>>> the actual, *independent* program P(P).
So in other words you insist on not going through my steps
(a)(b)(c)(d) on page 6 and trying to find an error?
I already pointed out that your (b) has major errors in an earlier
post which you disregarded. I see no reason to repeat that.
I am not willing to talk about anything else.
I am not willing to talk about anything besides page 6 until we have
mutual agreement on page 6.
That's not going to happen since your argument on page 6 is fallacious.
Read my earlier message <sebtb9$plb$1@dont-email.me>
I see no reason to repeat it.
olcott <NoOne@NoWhere.com> writes:
On 8/1/2021 7:41 AM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:I case there is some confusion, I mean that PO's Ĥ is not an Ĥ as
It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's >>>>> behaviour "correct". You can call it anything you like. But it's not >>>>> "as in Linz". It does not say anything about Linz's proof. It does not >>>>> do anything people would call impossible or even interesting.
whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
theorems are refuted. Which you would expect. If results were consistent >>>> it would have to be some cheap trick.
specified in Linz. Yes, everything is in accordance with the truth as
laid out in Linz and, indeed, in any textbook.
I point this out to PO because he brings it up. He keeps posting the
specification of what an Ĥ, as Linz specifies it, would do:
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if (and only if) M applied to wM does not halt.
He claims (or used to claim) that his Ĥ meets this specification for at >>> least the one case where wM == ⟨Ĥ⟩:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
To remain relevant, he /must/ keep insisting that his Ĥ meets the
requirements laid out in Linz, if only for this one key input.
Ĥ[0].q0 is taken to mean Ĥ<sub>0</sub>.q0 which is the Turing machine.
Ĥ[1].q0 is taken to mean Ĥ<sub>1</sub>.q0 which is the Turing machine
description input to Ĥ[0].q0
Ĥ[2].q0 is taken to mean Ĥ<sub>2</sub>.q0 which is first copy of the
Turing machine description input to Ĥ[0].q0
Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn
Ĥ[0] is Ĥ so you are confirming, yet again, that
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
It is neither a contradiction nor a paradox because there are three
different instances of Ĥ.
I agree that this is neither a paradox nor a contradiction. It's just a
fact derived form the logic of how your Ĥ is written (the majority of
which you are keeping hidden from us).
Because the only reason that the first instance halts is that Ĥ[0].qx
correctly determines that its input cannot possibly ever reach its
final state of Ĥ[1].qn or Ĥ[1].qy whether or not the simulating halt
decider aborts its simulation of this input, we know with 100%
perfectly justified logical certainty that the input to Ĥ[0].qx never
halts.
We know, since you keep telling us, that Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn. This clearly
shows that Ĥ applied to ⟨Ĥ⟩ halts. You can see the final state right
there in the line you keep posting again and again. As far as I know,
you have never disputed this fact.
As you say, this is neither a paradox nor a contradiction. It just
shows that Ĥ does not behave as Linz says it should, in the one case you have obsessed about for 17 years. Having an H (and thus an Ĥ) that is
wrong (i.e. not "exactly and precisely as on Linz" as you once claimed)
is trivial. It is not something that anyone (except Malcolm,
apparently) would care about.
olcott <NoOne@NoWhere.com> writes:
On 8/2/2021 8:45 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 8/2/2021 7:11 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
(I'm going to ignore errors that I've already pointed out.)
If you really do sincerely want an actual honest dialogue you wouldIf you want me to comment on that, write it without the errors. It has
carefully work through all the steps to confirm that the input ⟨Ĥ⟩ ⟨Ĥ⟩
to Ĥ.qx never halts.
two, both of which I've commented on before. If you are sincere, you
will want to write clearly and without errors.
Once we have mutual agreement that Ĥ.qx correctly decides that itsThere is no paradox. That Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn when Ĥ applied to ⟨Ĥ⟩
input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts and Ĥ does halt, then we have the basis to
go to the next step and resolve the actual paradox.
clearly halts is not paradoxical. It's just not the sort of TM the
proof is talking about. And how could it be? The "Linz Ĥ" is as
illogical as a cat that is a dog.
As long as it is simply dismissed out-of-hand as a contradiction theThere is no contradiction or paradox. You Ĥ is just the wrong sort of
paradox remains unresolved.
TM. The proof you want to "refute" is talking about this sort of Ĥ:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Maybe saying it a couple more times will help. After four times I can
tell you that it's still wrong. Maybe about a dozen more?
Whether what happens after Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is correct or not is determined
by Linz, not by you. And you are clear that
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn.
Linz is equally clear that this is wrong. You even helpfully keep
quoting Linz telling you it's wrong:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
You can repeat, again and again, that "Ĥ.qx correctly decides"
something, but you've already told the world that the computation halts
when is should not. Your Ĥ is not doing what it should to show a fault
in Linz's proof. It's doing something else that is of no interest to
anyone.
(It's possible that just can't see why it is that those two lines from
Linz are telling you that your Ĥ does is wrong. You've struggled with
what this notation really means, so it's possible. But reasonable
student would ask if they could not see that Linz is telling you your Ĥ
is wrong.)
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and
an input, whether the program will finish running, or continue to run
forever https://en.wikipedia.org/wiki/Halting_problem
Really? Well scan my tape and call me halting!
If you had had the two TMs you lied about having (sorry, used "poetic license" to say you had) you could have run
Ĥ.q0 ⟨Ĥ⟩
and
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩
and you would have seen, right away, that H(⟨Ĥ⟩ ⟨Ĥ⟩) is wrong about Ĥ(⟨Ĥ⟩). Maybe you did and that's why you've spent 30 months waking back
that lie^H^H^H poetic license.
olcott <NoOne@NoWhere.com> writes:
On 8/1/2021 11:00 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
On 8/1/2021 7:41 AM, Ben Bacarisse wrote:Ĥ[0] is Ĥ so you are confirming, yet again, that
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:I case there is some confusion, I mean that PO's Ĥ is not an Ĥ as
It seems to be established that H(H_Hat, H_Hat) returns "non-halting" >>>>>> whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no >>>>>> theorems are refuted. Which you would expect. If results were consistent >>>>>> it would have to be some cheap trick.
Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
behaviour "correct". You can call it anything you like. But it's not >>>>>>> "as in Linz". It does not say anything about Linz's proof. It does not >>>>>>> do anything people would call impossible or even interesting.
specified in Linz. Yes, everything is in accordance with the truth as >>>>> laid out in Linz and, indeed, in any textbook.
I point this out to PO because he brings it up. He keeps posting the >>>>> specification of what an Ĥ, as Linz specifies it, would do:
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if (and only if) M applied to wM does not halt.
He claims (or used to claim) that his Ĥ meets this specification for at >>>>> least the one case where wM == ⟨Ĥ⟩:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
To remain relevant, he /must/ keep insisting that his Ĥ meets the
requirements laid out in Linz, if only for this one key input.
Ĥ[0].q0 is taken to mean Ĥ<sub>0</sub>.q0 which is the Turing machine. >>>>
Ĥ[1].q0 is taken to mean Ĥ<sub>1</sub>.q0 which is the Turing machine >>>> description input to Ĥ[0].q0
Ĥ[2].q0 is taken to mean Ĥ<sub>2</sub>.q0 which is first copy of the >>>> Turing machine description input to Ĥ[0].q0
Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
It is neither a contradiction nor a paradox because there are threeI agree that this is neither a paradox nor a contradiction. It's just a >>> fact derived form the logic of how your Ĥ is written (the majority of
different instances of Ĥ.
which you are keeping hidden from us).
Because the only reason that the first instance halts is that Ĥ[0].qx >>>> correctly determines that its input cannot possibly ever reach itsWe know, since you keep telling us, that Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn. This clearly
final state of Ĥ[1].qn or Ĥ[1].qy whether or not the simulating halt >>>> decider aborts its simulation of this input, we know with 100%
perfectly justified logical certainty that the input to Ĥ[0].qx never >>>> halts.
shows that Ĥ applied to ⟨Ĥ⟩ halts. You can see the final state right >>
if M applied to wM halts, and
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
You are using the wrong Ĥ.
First of all, let's be 100% clear: I am talking about what /your/ Ĥ
does, based in the facts you have let slip about it.
Linz stipulates that wM is ⟨Ĥ⟩ and M is the underlying machine of this >> ⟨Ĥ⟩ therefore M applied to wM means ⟨Ĥ⟩ applied to ⟨Ĥ⟩.
No. How many years have you been staring at this one page from Linz?
You still don't know what it says. Do ask me questions, if you'd like
to know what the text you've been sure is wrong for 17 years really
says.
olcott <NoOne@NoWhere.com> writes:
On 8/4/2021 7:53 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 8/2/2021 8:45 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
As long as it is simply dismissed out-of-hand as a contradiction the >>>>>> paradox remains unresolved.
There is no contradiction or paradox. You Ĥ is just the wrong sort of >>>>> TM. The proof you want to "refute" is talking about this sort of Ĥ: >>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Maybe saying it a couple more times will help. After four times I can
tell you that it's still wrong. Maybe about a dozen more?
Whether what happens after Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is correct or not is determined
by Linz, not by you. And you are clear that
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn.
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
As explained in complete detail below:
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Yes, please don't tell me the final state yet again. This is not been
in dispute for some time.
because M applied to wM does not halt
where M is Machine_of(⟨Ĥ⟩) (1st param) above
and wM is ⟨Ĥ⟩ the second param above.
Because wM is referring to ⟨Ĥ⟩ and M is referring to the underlying
machine of ⟨Ĥ⟩ the last line above is translated to: if
Machine_of(⟨Ĥ⟩) applied to ⟨Ĥ⟩ does not halt
That's convoluted. ⟨Ĥ⟩ is the encoding of Ĥ so to find out what Linz expects from Ĥ applied to ⟨Ĥ⟩ we just substitute M = Ĥ and wM = ⟨Ĥ⟩ into
the above:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
We can know that Machine_of(⟨Ĥ⟩) applied to ⟨Ĥ⟩ never reaches its
Machine_of(⟨Ĥ⟩) = Ĥ.
final state whether or not the embedded halt decider at Ĥ.qx aborts it
You keep telling me that Ĥ applied to ⟨Ĥ⟩ reaches a final state. You even tell me the final state.
simulation of Machine_of(⟨Ĥ⟩), therefore we know that Machine_of(⟨Ĥ⟩)
never halts. Therefore we know that M applied to wM does not halt.
You keep telling me that Ĥ applied to ⟨Ĥ⟩ reaches the final state Ĥ.qn.
Are you changing your mind after all this time? No, you are searching
for some form of words that will make the wrong answer sound right.
On Thursday, 5 August 2021 at 04:18:21 UTC+1, olcott wrote:
On 8/4/2021 6:22 PM, Ben Bacarisse wrote:H_Hat <H_Hat> halts. So if it is simulated by a UTM, the simulation
olcott <No...@NoWhere.com> writes:When Bill says that his identical twin brother is not going to go to the
If the various strings you've chosen to number (badly) are not identical >>> then your "hat" construction is wrong. Linz's "hat" version makes an
exact copy.
store, and then Bill goes to the store this does not make him a liar.
You are free to write ⟨Ĥ[99]⟩ if you like, but I am also free to changeĤ is not a string it is a Turing machine.
that back to ⟨Ĥ⟩ because they are identical strings. Anything true of >>>
Turing machines are not identical to strings.
Ĥ halts the simulation of ⟨Ĥ⟩ on ⟨Ĥ⟩ never reaches its final state
whether or not the halt decider at Ĥ.qx stop simulating it.
If you want an actual honest dialogue we must have closure on some of
the points. You must say what things you agree with and not merely
ignore those things that you agree with.
Do you understand that the simulation of ⟨Ĥ⟩ on ⟨Ĥ⟩ never reaches its
final state whether or not the halt decider at Ĥ.qx stop simulating it?
UTM <H_HAT><H_Hat> also halts.
But the halt decider embedded in H_Hat is not a UTM. It's a near UTM,
that has abort logic. Somewhere the abort logic must be triggered,
which causes H_Hat<H_Hat> to halt.
H<H_Hat><H_Hat> also triggers this abort logic, so H<H_Hat><H_Hat>
reports "false" (non-halting).
We agree that H_Hat<H_Hat> halts.
If you disagree then to prove that you are not simply being disagreeable
you must proceed with a dialogue on this single point until we reach
mutual agreement. All other points will not be discussed until we reach
mutual agreement on this point.
We agree that H <H_Hat> <H_Hat> reports "false" (non-halting).
Can't you see the obvious?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 89:08:18 |
| Calls: | 6,658 |
| Files: | 12,203 |
| Messages: | 5,334,022 |