Richard Damon <Richard@Damon-Family.org> writes:
On 11/10/21 8:36 AM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:
On 11/10/21 6:35 AM, Ben Bacarisse wrote:I disagree (though it's largely philosophical at this point). From the
olcott <NoOne@NoWhere.com> writes:
Here is the same thing using Peter Linz notation:Oh dear, back to talking about Turing machines...
In this Linz machine:There is no string ⟨Ĥ⟩, so there is nothing that can be simulated. You
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
it is true that the correct pure simulation of the
input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
keep removing the clause that defines Ĥ's behaviour:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
With that clause put back, you (well, other people at least) can see >>>>> that no TM can behave like this.
But, if you step back a bit and ask about the H^ based on a machine H
that CLAIMS to meet the requirements, then you can have a H^ and a
<H^>.
claim that H meets Linz's spec we can deduce all sort of things. One of >>> which is that there is no string <H^>. But can also deduce any other
contradiction you like.
And that's the trouble. Anything PO says about such an H^ is validly
entailed by the assumption. He can even claim that 1 == 0 follows from
"Linz's specs", and he'd be right. At some stage you have to point out
the contradictions and force PO to abandon the initial assumption.
I, for one, am fed up with trying to explain ever more silly
consequences of the initial assumption about H. The proof is simple and >>> the contradiction entailed is obvious.
The difference is that PO HAS an H, so H does exist, and we can thus
build a H^ from. (This assumes we can convert is 'C Program' into some
sort of Turing Machine).
Not in this sub-thread. He starts: "In this Linz machine:" and then
gives the line he say not yet understood. He calls everything H, but
when it's Linz's we must assume what Linz assumes.
When H refers to his code, it's wrong for the reasons you and André and
I have been saying. If it's Linz H, it does not exist (or the class of
TMs referred to by H is empty).
Anyway, I'm butting out. If I've written out the proof using TMs more
than once, and the world has told him that his C code is wrong by
definition, but there is no way he will ever see any of this. It's not
that he's stupid, it's just that he's invested a significant proportion
of his life, and most of his self-esteem, in this ill thought out idea.
The mind will play extraordinary tricks in that sort of situation.
Indeed. So tell PO that there is no string <H^>. If there were, there
wold be a TM H^ halts if it does not and does not halt if it does.
Except that you can create an machine H that you can (incorrectly)
claim to meet the requirements, and thus a machine H^ can be created
and thus the string <H^> exists.
If he starts "my H" then yes, but he started "this Linz machine". Of
course calling everything H is just another silly thing he does, but
there is "Linz's H" which does not exist, and "his H" which does not
meet Linz's specification.
Olcott is barking up the wrong tree re infinite recursion: there
is only a need to detect a single recursive call into the halt decider
and signal an exception. Why? Because infinite recursion is valid
program behavior.
/Flibble
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 366 |
Nodes: | 16 (2 / 14) |
Uptime: | 02:42:47 |
Calls: | 7,812 |
Calls today: | 15 |
Files: | 12,924 |
Messages: | 5,749,456 |