Re: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT

On 4/15/2025 2:50 PM, olcott wrote:

On 4/15/2025 11:05 AM, dbush wrote:

On 4/15/2025 11:29 AM, olcott wrote:

On 4/15/2025 3:25 AM, Mikko wrote:

On 2025-04-15 03:41:02 +0000, olcott said:
>

On 4/14/2025 8:45 PM, Richard Heathfield wrote:

On 15/04/2025 02:18, olcott wrote:

On 4/14/2025 7:39 AM, Richard Heathfield wrote:

On 14/04/2025 12:56, olcott wrote:
>
<snip>
>

When people insist that a termination analyzer reports
on behavior other than the behavior that its finite string
input specifies this is isomorphic to requiring a perfectly
geometric square circle in the same two dimensional plane,
simply logically impossible, thus an incorrect requirement.

>
A termination analyzer that works is simply logically impossible, thus an incorrect requirement.
>

>
THAT IS A STUPID THING TO SAY THAT COMPLETELY IGNORES WHAT
COMPUTABLE FUNCTIONS ARE AND HOW THEY WORK.

>
You said precisely the same thing in reply to dbush. I have addressed your remark there, so I see no value in repeating my reply here.
>

HHH CORRECTLY REPORTS ON THE PATHOLOGICAL SELF-REFERENCE THAT
ITS INPUT SPECIFIES. THE DIRECT EXECUTION HAS NO SUCH PSR.

>
You say so,

>
Ignoring verified facts does not make them go away.

>
Ignoring verified proofs does not meke them go away.
But you keep ignoring them anyway.
>

>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
It is a verified fact that the input to HHH(DD) specifies
>

>
An algorithm which halts when executed directly.
>

>
It is flat out stupid to think that HHH should report on
behavior other than this specified behavior. Only people
that have zero depth of understanding would suggest this.

>
No, it is flat-out stupid to think that something that claims to be a halt decider / termination analyzer should report on anything other than the mapping which is the halting 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
>

>
a function is computable if there exists an
algorithm that can do the job of the function,
i.e. given an input of the function domain it
can return the corresponding output.
>
https://en.wikipedia.org/wiki/Computable_function

>
And the mathematical halting function is not a computable function, as proven by Linz and others
>

>
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
>
Not freaking allowed to look at any damn thing
else besides the freaking input. Must compute whatever
mapping ACTUALLY EXISTS FROM THIS INPUT.
>

>
So the algorithm HHH that you've implemented computes *some* computable function, but it does not compute the halting function as it is not computable.
>
>

 *corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
Knucklehead !!!
 

That doesn't refute anything I said.
Again, the HHH you've implemented computes *some* computable function, but it doesn't compute the mathematical halting function because it is not a computable function.
Remember, as per the definition you quoted above, a computable function is simply a mathematical mapping that happens to have an algorithm that can compute it.  HHH itself is *not* a computable function, but an algorithm that computes a computable function.
If you continue to say "computable function" when you mean "algorithm", I will take the liberty of replacing the former with the latter in your quotes and respond accordingly.