Re: Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite Recursion ZFC

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

On 24/05/2025 01:36, Keith Thompson wrote:

Ben Bacarisse <ben@bsb.me.uk> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Ben Bacarisse <ben@bsb.me.uk> writes:
[...]

And the big picture is that this can be done because false is the
correct halting decision for some halting computations.  He has said
this explicitly (as I have posted before) but he has also explained it
in words:
>
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.

>
Hmm.  I don't read that the way you do.  Did I miss something?
>
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
>
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.

>
It would be a tautology but for the "unless..." part.  It does not make
the determination that it does not halt.  It determines that it would
not halt were it not for the fact that the decider (a simulation) in
fact halts it.

Right, so the computation itself is non-halting. 

>
No no no, it halts!

What halts?

                     (Assuming we're discussing the computation DD() with PO's code.)

No, I'm not going to assume that.  *All* I'm talking about is olcott's
statement:

| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.

I'm not trying to make it consistent with anything else olcott has
written.  DD() is irrelevant to what I'm talking about.

As I wrote before, let H be the "halt decider" and let I be its input
(which represents a computation).  I by itself does not halt.
I-simulated-by-H may halt if H forces it to halt.

H might be a simulator, or it may just monitor the execution of I with
the ability to halt it.  H is not a pure simulator; it does not always
fully simulate the execution of I.

H is given the task of determining whether I is a halting computation or
not (a task that is not possible in all cases, but is certainly possible
in some cases).

[...]

[Bear in mind that with PO's HHH(DD), it /incorrectly/ determines that
its input doesn't halt.  But sure, the statement as you're reading it
is a tautology.  That tautology just doesn't apply to PO's HHH(DD).]

I never said it did or did not apply to PO's HHH(DD).  I said the
statement is a tautology, and apparently you agree -- but you disagree
with *something* you think I said.

So how does PO's reading differ?  The problem is with your phrase "its
input doesn't halt".  That's fine wording, directly invoking the
/definition/ of "halt", which most people understand, but PO CAN'T DO
ABSTRACT.  In his head he has replaced the definition with something
he /can/ cope with - some "concrete" procedure he can imagine
performing, involving simulations and amended code.  So what exactly
is this concrete procedure PO imagines?

That's not relevant to what I'm talking about.  I take no position on
whether olcott understands his own statement.  I'm merly saying that
that one statement is true, and is a tautology, and is not particularly
interesting.  I get the impression that others are insisting on
interpreting the one statement in the context of other things olcott
has written.

[...]

So sure, you can say the statement is a tautology, but PO made that
statement and his interpretation of what it means is far from your
tautology.

Sure, he does that.

My overall point, I suppose, is that if people are going to argue with
olcott, if he happens to make a true statement it's not helpful to argue
that its false.

HTH (if only in sending you off on a good night's sleep!)
Mike.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */