Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: =?UTF-8?Q?Re=3A_Analysis_of_Flibble=E2=80=99s_Latest=3A_Detecting_v?=
 =?UTF-8?Q?s=2E_Simulating_Infinite_Recursion_ZFC?=
Date: Sun, 25 May 2025 12:51:47 +0200
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <100uso4$1b469$2@dont-email.me>
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> <100r2mb$b2b1$1@dont-email.me>
 <87msb2x39x.fsf@bsb.me.uk> <87tt5aslwo.fsf@nosuchdomain.example.com>
 <87bjrhwlqr.fsf@bsb.me.uk> <100tq4c$110ge$1@dont-email.me>
 <100tqeg$110ge$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 25 May 2025 12:51:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="59d5741c0b711edff35e33d70aad8f77";
	logging-data="1413321"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/lP6Ntvn0T9czw23oSlaOS"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JEoaftNkqE5P5JXVPLb6A1V/Yi4=
Content-Language: nl, en-GB
In-Reply-To: <100tqeg$110ge$5@dont-email.me>
Bytes: 6975

Op 25.mei.2025 om 03:06 schreef olcott:
> On 5/24/2025 8:01 PM, olcott wrote:
>> On 5/24/2025 7:57 PM, Ben Bacarisse wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>> On 23/05/2025 19:37, Keith Thompson wrote:
>>>>>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> 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.
>>>>>>
>>>>>> You're reading it the way most people would, and in the way I said 
>>>>>> Sipser
>>>>>> would be interpreting the oft-quoted "Sipser quote".  I don't 
>>>>>> think you've
>>>>>> missed anything particularly.
>>>>>
>>>>> Maybe it makes less sense out of the context it was posted in.  
>>>>> This was
>>>>> when he was being less obtuse.  The computation in question only halts
>>>>> because it is halted by the decider on which it is built.  It is a
>>>>> halting computation, but according to PO it can reported as not 
>>>>> halting
>>>>> because of what would happen if it were not halted by the decider from
>>>>> which it is derived.
>>>>
>>>> I think you're misreading it (or, if you prefer, I have yet to be
>>>> convinced that I'm misreading it).
>>>
>>> OK.  This sub thread is an excellent example of how cranks keep it all
>>> going without shining any light on what's going on.
>>>
>>> If the remark is correct, then it misrepresents PO's intended meaning
>>> because he is discussing one of the cases where false is the correct
>>> result for a halting computation.  If the remark does represent his
>>> intended meaning then it is unclear because you think it is simply a
>>> tautology.
>>>
>>> That makes it a bad quote for me to have pulled out.  I should have
>>> stuck with this exchange:
>>>
>>> Me: Here's the key question: do you still assert that H(P,P) == false is
>>>      the "correct" answer even though P(P) halts?
>>>
>>> PO: Yes that is the correct answer even though P(P) halts.
>>>
>>> Everything that followed this was, as far as I can tell, an attempt be
>>> less clear.  But as Richard Heathfield has pointed out, we should always
>>> attempt to address the strongest and clearest-made point that is
>>> offered.  (I think this advice was originally from Daniel Dennet.)
>>>
>>> I see you have offered a very detailed interpretation of what you think
>>> the words used by PO mean.  Please forgive me for not going into it in
>>> any more detail.  I'll just take that to mean PO was unclear and should
>>> not have quoted his ambiguous words.  When PO is clear, he is very
>>> explicitly wrong, and that's the main point that keeps getting lost.
>>>
>>
>> _DDD()
>> [00002192] 55             push ebp
>> [00002193] 8bec           mov ebp,esp
>> [00002195] 6892210000     push 00002192
>> [0000219a] e833f4ffff     call 000015d2  // call HHH
>> [0000219f] 83c404         add esp,+04
>> [000021a2] 5d             pop ebp
>> [000021a3] c3             ret
>> Size in bytes:(0018) [000021a3]
>>
>> Since it is an easily verified fact that DDD emulated
>> by HHH according to the rules of the x86 language
>> would never stop running unless aborted by HHH:
>>
>> I can't imagine how anyone disagreeing with this
>> is not a damned liar. If anyone disagrees knowing
>> that they simply don't understand these things
>> they too are also damned liars.
>>
>>
> 
> int main()
> {
>    DDD();  // No matter what the f-ck its caller does
> }         // The finite string input to the HHH(DDD)
>            // that DDD() calls SPECIFIES a non-halting
>            // sequence of configurations.
No, the input is a pointer to memory. That memory includes the code of 
DDD and all functions it calls, in particular it includes the code to 
abort and halt.
That HHH, due to a bug, is blind for that specification, does not change 
the specification of a halting program.