Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.theory
Subject: Re: Analysis of =?utf-8?Q?Flibble=E2=80=99s?= Latest: Detecting vs.
 Simulating Infinite Recursion ZFC
Date: Sat, 24 May 2025 14:40:24 -0700
Organization: None to speak of
Lines: 103
Message-ID: <87ldqlsn5j.fsf@nosuchdomain.example.com>
References: <Ms4XP.801347$BFJ.668081@fx13.ams4>
	<100l3jh$2v0e9$1@dont-email.me> <100l5c8$2ul3j$2@dont-email.me>
	<100l75g$2vpq3$1@dont-email.me> <100l887$2ul3i$2@dont-email.me>
	<100l9gh$30aak$1@dont-email.me> <100lc4o$30pgm$1@dont-email.me>
	<100ld1u$312c9$1@dont-email.me> <100lg4g$31jt3$1@dont-email.me>
	<100lkdv$32ib3$1@dont-email.me> <100lmif$32v06$1@dont-email.me>
	<100lmp3$32ven$1@dont-email.me> <100m319$38k55$2@dont-email.me>
	<87jz69xlpx.fsf@nosuchdomain.example.com>
	<100mder$39slu$2@dont-email.me> <100oipb$3oge1$1@dont-email.me>
	<87a573xz0s.fsf@bsb.me.uk> <875xhrtbpr.fsf@nosuchdomain.example.com>
	<87y0umx63u.fsf@bsb.me.uk> <871pseu9os.fsf@nosuchdomain.example.com>
	<100ssg5$qc3d$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sat, 24 May 2025 23:40:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0ba1c539592a7bdafac6a495dcd9bfcd";
	logging-data="989741"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18lecxl9RqHLFwQ3G4TOVxL"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:VQgI0HHelwHuKGR1QcgUdyvwpoo=
	sha1:aNfQr6obREUdYrMCzDbr4xxdE48=
Bytes: 6098

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 */