Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@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 12:33:11 -0400
Organization: A noiseless patient Spider
Lines: 167
Message-ID: <100ssc6$qa2s$1@dont-email.me>
References: <Ms4XP.801347$BFJ.668081@fx13.ams4>
 <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>
 <100sn6a$p071$1@dont-email.me> <100snl3$nvac$1@dont-email.me>
 <100sr6o$ppn2$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 18:33:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7bffcf1a053bdddb0127a83d4984dc7b";
	logging-data="862300"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QDgPACbfLEUmc+aMDdlk1"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9sF+q4LwM+fpqco/Zymne22NNkU=
In-Reply-To: <100sr6o$ppn2$3@dont-email.me>
Content-Language: en-US

On 5/24/2025 12:13 PM, olcott wrote:
> On 5/24/2025 10:12 AM, dbush wrote:
>> On 5/24/2025 11:04 AM, olcott wrote:
>>> 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 ?
>>>
>>
>>
>> Which means that no HHH exists that meets the below requirements, as 
>> Linz and others proved and as you have *explicitly* agreed is correct:
>>
> 
> You are a damned liar when you say that I said
> that HHH must report on the behavior of its caller.
> 

Nope:


On 3/24/2025 10:07 PM, olcott wrote:
 > A halt decider cannot exist

On 4/28/2025 2:47 PM, olcott wrote:
 > On 4/28/2025 11:54 AM, dbush wrote:
 >> And the halting function below is not a computable function:
 >>
 >
 > It is NEVER a computable function
 >
 >> 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

On 3/14/2025 1:19 PM, olcott wrote:
 > When we define the HP as having H return a value
 > corresponding to the halting behavior of input D
 > and input D can actually does the opposite of whatever
 > value that H returns, then we have boxed ourselves
 > in to a problem having no solution.

On 6/21/2024 1:22 PM, olcott wrote:
 > the logical impossibility of specifying a halt decider H
 > that correctly reports the halt status of input D that is
 > defined to do the opposite of whatever value that H reports.
 > Of course this is impossible.

On 7/4/2023 12:57 AM, olcott wrote:
 > If you frame the problem in that a halt decider must divide up finite
 > strings pairs into those that halt when directly executed and those that
 > do not, then no single program can do this.

On 5/5/2025 5:39 PM, olcott wrote:
 > On 5/5/2025 4:31 PM, dbush wrote:
 >> Strawman.  The square root of a dead rabbit does not exist, but the
 >> question of whether any arbitrary algorithm X with input Y halts when
 >> executed directly has a correct answer in all cases.
 >>
 >
 > It has a correct answer that cannot ever be computed

On 5/13/2025 5:16 PM, olcott wrote:
 > There is no time that we are ever going to directly
 > encode omniscience into a computer program. The
========== REMAINDER OF ARTICLE TRUNCATED ==========