Re: Defining a correct halting decidability decider

On 2024-08-10 11:03:31 +0000, olcott said:

On 8/10/2024 3:20 AM, Mikko wrote:

On 2024-08-09 13:47:34 +0000, olcott said:
 

On 8/9/2024 3:56 AM, Mikko wrote:

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.

 https://en.wikipedia.org/wiki/Stipulative_definition
has_eaten_lunch is a Stipulative_definition defined below:
 A program is said to have the non trivial semantic
property of has_eaten_lunch when it halts and
~has_eaten_lunch when it cannot be correctly determined
to halt. This defeat Rice's Theorem.

 that is not a useful stipulation. And there is no way to correctly
determine that it is not possible to determine whether a computation
halts.

 1=halts
0=does not halt or pathological relationship to decider

Which does not use the stipulation and therefore does not demonstrate
its usefulńess.
That a computation has a pathological relationship to some decider
does not prevent another partial haltdecider from determinig whther
it halts.
--
Mikko