Re: What is the best way for termination analyzers to handle pathological inputs?

On 6/9/25 5:14 PM, olcott wrote:

The official "received view" of this is that the best
we can possibly do is to do nothing and give up.
 void DDD()
{
   HHH(DDD);
   return;
}
 The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state* because
this input specifies that HHH simulates itself simulating DDD.
 *Every rebuttal to this changes the words*
 

No, the input does NOT specify that, it specifies that HHH is to decide what a program that calls HHH will do. This means that HHH has to have already been defined as to what its algorithm is exactly. And thus the actual behavior of this action is fulled defined. The problem is that any HHH that uses your logic, gets the wrong answer.
Only if HHH is defined to just simulate its input do you get that implication, but then, as you have shown, such an HHH just fails to be a decider.
The best answer for a "termination analyzer" to do for the pathological case IS what you reject, admit that it can not get a correct answer, and report that. The best answer for the above DDD, is to recognize the pattern (if possible) and see that returning 1 would be correct.
It is a lot better than lying and giving the wrong answer.
All you are doing is showing that you fundamentally don't understand the meaning of the words you are using, ESPECIALLY the meaning of a "Program" as used in the context, and related words like "correct".