On 2021-08-30 08:35, olcott wrote:
My point is fully proven on the basis of two other points:
(1) Verified as true entirely on the basis of the meaning of its words:
Claiming that something is 'verified as true entirely on the basis of
the meaning of its words' isn't a valid substitute for a proof.
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
(2) It can be verified that the input to H(P,P) never halts unless H
aborts it. This is verified on the basis that the execution trace of P
meets this criteria:
where H = X() and P = Y()
Infinite recursion detection criteria:
If the execution trace of function X() called by function Y() shows:
(a) Function X() is called twice in sequence from the same machine
address of Y().
(b) With the same parameters to X().
(c) With no conditional branch or indexed jump instructions in Y().
(d) With no function call returns from X().
then the function call from Y() to X() is infinitely recursive.
First off, you simply state the above criteria without actually offering
any *proof* that these criteria actually work.
And second, even if these criteria are valid, your trace *doesn't*
actually meet these criteria because you deliberately omit portions of
the code from your trace (i.e. everything that happens starting at
address 966).
The claim that 'it can be verified that the input to H(P, P) never halts unless H aborts it.' Is not verified at all, since it can easily shown
to be false by simply observing the fact that P(P) does, in fact, halt.
You try to get around this by claiming that when you call H(P, P) the
input magically changes to some *other* computation which isn't
equivalent to P(P) and that this *other* computation is non-halting, but
even if such a claim made sense, it means your H is answering about the *wrong* computation.
And from your recent posts in a different thread, it appears you are
also claiming that it is not possible to even ask your H about the real
P(P), which is the case we're really concerned about.
If your H can't even be asked about the real P(P), then it isn't even answering the question a halt decider is supposed to answer. So what's
the point of your H?
André
olcott <NoOne@NoWhere.com> writes:
On 8/30/2021 11:01 AM, Malcolm McLean wrote:
On Monday, 30 August 2021 at 15:35:22 UTC+1, olcott wrote:
My point is fully proven on the basis of two other points:The sounds reasonable. But there are two Hes. The halt decider, and the
(1) Verified as true entirely on the basis of the meaning of its words: >>>> A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this >>>> input is an input that never halts.
(2) It can be verified that the input to H(P,P) never halts unless H
aborts it. This is verified on the basis that the execution trace of P >>>> meets this criteria:
copy of H in H_Hat. In your set up, these are physically the same piece
of machine code. That isn't fatal. But it does mean that we have to be
careful about what we mean by "unless H aborts it".
If we ran UTM<H_Hat><H_Hat> insread of H<H_Hat><H_Hat> what would
happen?
He won't answer that! Not because he does not know the answer but
because he does.
I am not referring to H_Hat any more. H/P is much more concise and
mathematical.
Translation: "I get burned every time I talk about Turing machines so
I'll stick with some C code and a function I won't publish".
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 366 |
Nodes: | 16 (2 / 14) |
Uptime: | 15:17:55 |
Calls: | 7,812 |
Files: | 12,927 |
Messages: | 5,766,041 |