Re: Defining a correct halting decidability decider

On 2024-08-08 13:21:57 +0000, olcott said:

On 8/8/2024 2:12 AM, Mikko wrote:

On 2024-08-07 13:12:43 +0000, olcott said:
 

On 8/7/2024 1:59 AM, Mikko wrote:

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

 A Conventional halt decider is 1 for halts and 0 for does not halt.

 That is because conventionally the question is "Does thing computation
halt?" so "yes" means the same as "halts".
 

0 also means input has pathological relationship to decider.

 It cannot mean both "does not halt" and "has pathological relationship
to decider". Those two don't mean the same.
 

In other words 1 means good input and 0 means bad input.

 That is not the same in other words.
 An input is good in one sense if it specifies a computation and bad if
it does not. In the latter case the decider is free to do anything as
the input is not in its scope.
 In another sense an input is good if it is as the user wants it to be.
If the user wants a non-halting computation then a halting one is bad.
 

 *Semantic property of well-behaved is decided for input*
It the program well behaved thus halts?
else The program is not well behaved.

You don't need any meaning for "well-behaved". A program is good if
it satisfies its purpose. Sometimes the purspose rquires that the
program halts, sometimes that it doesn't halt. Halt decider's
purpose is to predict whether a computation halts. A partial halt
decider satisfies this purpose in some but not all cases. A better
partial halt decider satisfies this purpose in more cases.
--
Mikko