Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
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: <Ms4XP.801347$BFJ.668081@fx13.ams4>
 <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 <X> with input Y:
> 
> A solution to the halting problem is an algorithm H that computes the 
> following mapping:
> 
> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
> (<X>,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