Re: Defining a correct halting decidability decider

On 2024-08-04 19:33:36 +0000, olcott said:

On 8/4/2024 2:05 PM, Richard Damon wrote:

On 8/4/24 2:49 PM, olcott wrote:

On 8/4/2024 1:38 PM, Richard Damon wrote:

On 8/4/24 10:46 AM, olcott wrote:

When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
 int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 int main()
{
   HHH(DD);
}
 HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.
 

 But false indicates that the input does not halt, but it does.
 

 I made a mistake that I corrected on a forum that allows
editing: *Defining a correct halting decidability decider*
1=input does halt
0=input cannot be decided to halt

 And thus, not a halt decider.
 Sorry, you are just showing your ignorance.
 And, the problem is that a given DD *CAN* be decided about halting, just not by HHH, so "can not be decided" is not a correct answer.

 A single universal decider can correctly determine whether
or not an input could possibly be denial-of-service-attack.
0=yes does not halt or pathological self-reference
1=no  halts

Conventionally the value 0 is used for "no" (for example, no errors)
and value 1 for "yes". If there are different "yes" results other
numbers in addition to 1 can be used. For example, for the question
"is there anu errors?" the number may identify the error. For a
partial halt decider the best values are
-1 = does not halt
0 = not determined
1 = halts.
In C the value 0 is interpreted as false and every other number,
positive or negative, is interpreted as true in every context
where a boolean value is expected.
--
Mikko