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
> screwy idea of a universal halt decider that is
> literally ALL KNOWING is just a screwy idea.
Re: Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite Recursion
Re: Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite Recursion