Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: "Fred. Zwarts" 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: <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 writes: >>> >>>> Ben Bacarisse writes: >>>>> Mike Terry writes: >>>>>> On 23/05/2025 19:37, Keith Thompson wrote: >>>>>>> Ben Bacarisse writes: >>>>>>>> Mike Terry 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.