Re: My reviewers think that halt deciders must report on the behavior of their caller

On 6/5/25 12:25 PM, olcott wrote:

On 6/5/2025 6:06 AM, Richard Damon wrote:

On 6/4/25 10:44 PM, olcott wrote:

On 6/4/2025 9:13 PM, dbush wrote:

On 6/4/2025 10:09 PM, olcott wrote:

On 6/4/2025 8:43 PM, Richard Damon wrote:

On 6/4/25 11:50 AM, olcott wrote:

On 6/4/2025 2:04 AM, Mikko wrote:

On 2025-06-03 21:39:46 +0000, olcott said:
>

They all say that HHH must report on the behavior of
direct execution of DDD()

>
No, they don't say that. A halting decider (and a partial halting
decider when it reports) must report whether the direct execution
of the computation asked about terminates. Unless that computation
happens to be DDD() it must report about another behaviour instead
of DDD().
>

yet never bother to notice that the directly executed DDD() is
the caller of HHH(DDD).

>
To say that nobody has noticed that is a lie. Perhaps they have not
mentioned what is irrelevant to whatever they said. In particular,
whether DDD() calls HHH(DDD) is irrelevant to the requirement that
a halting decider must report about a direct exection of the
computation the input specifies.
>

>
*People have ignored this for 90 years*
*People have ignored this for 90 years*
*People have ignored this for 90 years*
>
The only possible way that HHH can report on the
direct execution of DDD() is for HHH to report on
the behavior of its caller:

>
So?
>
It *IS* a fact that to be correct, it needs to answer about the direct executiom of the program that input represents.
>
That is DEFINITION.
>

>
Likewise with the definition of Russell's Paradox
until ZFC showed that this definition is complete
nonsense.
>

>
But unlike Russel's Paradox, which showed a contradiction in the axioms of naive set theory, there is no contradiction in the axioms of computation theory.  It follows from those axioms that no H exists that performs the below mapping, as you have *explicitly* agreed.
>

>
int main()
{
   DDD(); // comp theory does not allow HHH to
}        // report on the behavior of its caller.
>

>
WHere do you get that from?
>
Your problem seems to be you don't know the meaning of the terms of the Theory.
>
You can't ask the question: "Does your caller Halt?"
>

 That is what I just said.

Right, which is an invalid question. As I

 

You can ask the question: "Does the program your input represents halt?"

 Too vague. Does the sequence of configurations that your input specifies
reach their own final halt state?

That is the problem for HHH to determine.
It turns out, the answer is YES, as your HHH has been defined to return 0 for this input.

 

even when that input represents its caller, because who the caller is doesn't affect that answer.
>

 Completely different process contexts cannot be equated.

Exactly equal code descriptions can be.
Programs don't depend on their "process contexts", only their code and their input.

 

All you are doing is showing that you have a fundamental error in your view of the theory, not understanding the basic concepts.

 If everyone else is wrong their wrong headed agreement may
make it seem that I am wrong.
 

No, YOU ARE WRONG.
That you are too stupid to understand that, just shows how stupid you are.
If you even TRY to find a logical rebutal, backed by factual definitions for reputable sources, you might learn something.
It seems you world is based on the idea that you are right and everyone else is wrong, but you can't justify that except by your own claims, as you have shown you don't understand the meaning of the words you use.