Re: Everyone on this forum besides Keith has been a damned liar about this point

On 6/11/25 10:03 AM, olcott wrote:

On 6/11/2025 3:20 AM, Mikko wrote:

On 2025-06-10 15:41:33 +0000, olcott said:
>

On 6/10/2025 6:41 AM, Mikko wrote:

On 2025-06-10 00:47:12 +0000, olcott said:
>

On 6/9/2025 7:26 PM, Richard Damon wrote:

On 6/9/25 10:43 AM, olcott wrote:

On 6/9/2025 5:31 AM, Fred. Zwarts wrote:

Op 09.jun.2025 om 06:15 schreef olcott:

On 6/8/2025 10:42 PM, dbush wrote:

On 6/8/2025 11:39 PM, olcott wrote:

On 6/8/2025 10:32 PM, dbush wrote:

On 6/8/2025 11:16 PM, olcott wrote:

On 6/8/2025 10:08 PM, dbush wrote:

On 6/8/2025 10:50 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}
>
The *input* to simulating termination analyzer HHH(DDD)

>
No it's not, as halt deciders / termination analyzers work with algorithms,

>
That is stupidly counter-factual.
>

>
That you think that shows that

>
My understanding is deeper than yours.
No decider ever takes any algorithm as its input.

>
But they take a description/specification of an algorithm,

>
There you go.
>

which is what is meant in this context.

>
It turns out that this detail makes a big difference.
>

And because your HHH does not work with the description/ specification of an algorithm, by your own admission, you're not working on the halting problem.
>

>
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD.

>
And HHH fails to see the specification of the x86 instructions. It aborts before it can see how the program ends.
>

>
This is merely a lack of sufficient technical competence
on your part. It is a verified fact that unless the outer
HHH aborts its simulation of DDD that DDD simulated by HHH
the directly executed DDD() and the directly executed HHH()
would never stop running. That you cannot directly see this
is merely your own lack of sufficient technical competence.

>
And it is a verified fact that you just ignore that if HHH does in fact abort its simulation of DDD and return 0, then the behavior of the input, PER THE ACTUAL DEFINITIONS, is to Halt, and thus HHH is just incorrect.
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
How the f-ck does DDD correctly simulated by HHH
reach its own "return" statement final halt state?

>
If HHH is not a decider the question is not interesting.

>
I switched to the term: "termination analyzer" because halt deciders
have the impossible task of being all knowing.

>
The termination problem is in certain sense harder than the halting
problem.

 Not at all
 void DDD()
{
   HHH(DDD);
   return;
}
 If HHH only determines non-halting correctly for the
above input and gets the wrong answer on everything
else then HHH *is* a correct termination analyzer.

Nope. Not the definition.

 A halt decider would be required to determine if a
proof of the Goldbach conjecture halts not knowing
whether this proof is infinite or not.

Right, and so does a unqualified Termination Analyzer.
Where are you getting your definition?
Failure to answer is just an admission that you admit to just making things up.

 

In addition the concept "analyzer" is essentially different
from "decider". A decider is expected to answer "yes" or "no". A
partial decider is permitted to answer neither and instead to run
forever or to answer "cannot determine". An analyzer is expected to
provide useful information to the developers so that the can change
the program so that it can be trusted to have the required property.
>

Most people are confused by the term "partial halt decider".

>
I have seen evdence of that particular confusion.
>

 Most people don't know that a halt decider must be all knowing.
 

And you don't seem to understand that an unqualified claim of "Correct" for a decider/analyzer must also be "all knowing".