Re: Proving the: Simulating termination analyzer Principle

On 4/5/2025 7:59 PM, Richard Heathfield wrote:

On 06/04/2025 01:35, olcott wrote:

On 4/5/2025 5:31 PM, Richard Heathfield wrote:

On 05/04/2025 23:20, olcott wrote:

On 4/5/2025 4:58 PM, Richard Heathfield wrote:

>
<snip>
>

hp(arg candidate, arg testdata)
{
   if(terminates(candidate(testdata)))
   {
     while(forever);
   }
   else
   {
     halt;
   }
}
>
We then invoke the program:
>
hp(hp, hp)
>
and try to predict what terminates() will report, and of course the answer is that we don't know, because neither does terminates(). The function cannot be written.
>

>
Understanding my simpler example was a mandatory
prerequisite

>
No, it wasn't.
>
Understanding my example isn't mandatory either, which is just as well where you're concerned.
>

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

>
That's fine, but it does beg the HHH() question. You are handwaving it for the same reason I am, which is that it can't be written. The difference between us is that I know it and you don't.
>

>
HHH(DDD) is isomorphic to HHH(DD),

>
Irrelevant.
>

yet failing
to understand that HHH(DDD) meets the
*Simulating termination analyzer Principle*
prevents the significance of this from being seen.

>
It has no significance.
>
There are only two possibilities: either it always gives the right answer or it doesn't. If it gives the wrong answer, it's of no interest.
>
If it is claimed always to give the right answer, it becomes possible (as shown above in the chevrons) to write a program for which it will not be able to work out the right answer - reductio ad absurdum.
>
Your 'principle' doesn't matter a jot.
>

 Except that it gives the correct
*Simulating termination analyzer Principle*
answer for the Halting Problems impossible input.
The computer science of termination analyzers might agree.