Re: Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite Recursion ZFC

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.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer