Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott 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: Sat, 24 May 2025 10:04:42 -0500 Organization: A noiseless patient Spider Lines: 99 Message-ID: <100sn6a$p071$1@dont-email.me> References: <100kt0c$2tae8$3@dont-email.me> <100ktr7$2reaa$1@dont-email.me> <100l09v$2tae8$5@dont-email.me> <100l1ov$2ul3j$1@dont-email.me> <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> <100r4oq$b650$1@dont-email.me> <100r5bf$b5vm$4@dont-email.me> <100r5hn$b650$2@dont-email.me> <100r648$bhcu$1@dont-email.me> <100r68v$b650$3@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 24 May 2025 17:04:43 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f513fb0f9fd54277dcf2467a994ccda0"; logging-data="819425"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/k9PdBtcxUDok9dxsl/A3Z" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:9zKfeX68piwH3xiiIoP9Rjn2OXw= X-Antivirus: Norton (VPS 250524-2, 5/24/2025), Outbound message In-Reply-To: <100r68v$b650$3@dont-email.me> X-Antivirus-Status: Clean Content-Language: en-US On 5/23/2025 8:09 PM, dbush wrote: > On 5/23/2025 9:07 PM, olcott wrote: >> On 5/23/2025 7:57 PM, dbush wrote: >>> On 5/23/2025 8:54 PM, olcott wrote: >>>> On 5/23/2025 7:44 PM, dbush wrote: >>>>> On 5/23/2025 8:08 PM, Mike Terry wrote: >>>>>> I suppose Ben quoted PO saying this, because PO /uses/ it to >>>>>> justify that a particular /halting/ computation will never halt, >>>>>> PO's HHH simulates DDD (which halts) but before DDD halts it spots >>>>>> a pattern in the simulation, and announces non-halting.  "Eh?" I >>>>>> hear you say! PO claims HHH has "correctly determined that DDD >>>>>> would never halt" and so is correct to decide non-halting.  His >>>>>> "proof" that it is right to decide non-halting is his "when-so- >>>>>> ever.." quote, which broadly matches the Sipser quote. >>>>>> >>>>>> So the problem is not so much the "when-so-ever.." words >>>>>> themselves [or the words of Sipser's quote], but understanding how >>>>>> PO is so thoroughly misinterpreting/misapplying them.  How can PO >>>>>> believe HHH has "correctly determined the DDD will never halt" >>>>>> when DDD demonstrably halts? >>>>> >>>>> PO is working in a different model than the rest of us, though he >>>>> doesn't seem to understand that. >>>>> >>>>> To him, when function H is deciding on something, the >>>>> implementation of H is allowed to vary.  This results in functions >>>>> that call H to vary as a result.  To him, "DDD" is the same >>>>> computation *regardless of the implementation of HHH*, in cases >>>>> where HHH is simulating DDD. >>>>> >>>>> This is essentially the mapping he's operating with: >>>>> >>>>> ----------------- >>>>> For a function X with input Y and a function H which simulates X: >>>>> POH(H,X,Y)==1 if and only if there exists an implementation of H >>>>> that can simulate X(Y) to completion >>>>> POH(H,X,Y)==0 if and only if there does not exist an implementation >>>>> of H that can simulate X(Y) to completion >>>>> ---------------- >>>>> >>>>> And a "decider" in his case maps the following subset: >>>>> >>>>> ---------------- >>>>> Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y) >>>>> ---------------- >>>>> >>>>> So given his rules, HHH1(DDD) is deciding on a algorithm while >>>>> HHH(DDD) is deciding on a C function whose subfunctions vary. >>>>> >>>>> This of course has nothing to do with the halting problem but he >>>>> doesn't get this.  After having spent 22 years on this, he'll come >>>>> up with any crazy justification to avoid admitting to himself that >>>>> he misunderstood the problem all this time.  He once said (and I >>>>> don't recall the exact wording) that "the directly executed D >>>>> doesn't halt even though it appears to". >>>> >>>> The problem is that people here are too stupid >>>> to notice that HHH cannot report on the behavior >>>> of its caller. >>>> >>>> int min() >>>> { >>>>    DD(); // HHH cannot report on the behavior of its caller. >>>> } >>>> >>> >>> What about this? >>> >> >> If you can't stay exactly on topic I am going to ignore >> everything that you say. >> >> HHH cannot report on the behavior of its caller AKA the >> direct execution of DD(). >> > > > In other words, you again agree with Linz and others that no H exists > that can perform the following mapping: > > > Given any algorithm (i.e. a fixed immutable sequence of instructions) X > described as with input Y: > > A solution to the halting problem is an algorithm H that computes the > following mapping: > > (,Y) maps to 1 if and only if X(Y) halts when executed directly > (,Y) maps to 0 if and only if X(Y) does not halt when executed directly > int main() { DD(); // The HHH called by DD cannot report on the behavior } // of its caller. Is this OVER-YOUR-HEAD ? -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer