Re: Defining a correct halting decidability decider

On 8/9/24 9:47 AM, olcott wrote:

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.
 

But, to be a property of an input, it must depend on ONLY that input, that that means that if ANY decider can properly decide on "has_eaten_lunch" for that input, it is decidable, since either M0 (the machine that answer 0 for all inputs) or M1 (the machine that answers 1 for all inputs) for THAT input (the particular DDD/HHH pairing that wants to call the input undecidable) the input IS decidable, it is just that THAT HHH get the answer wrong for THAT input.
Remember, the input is a FULL PROGRAM, and thus is the DDD "template" paired with a specific HHH to get a particular DDD program. (Giving the two the same name is just part of your attempt to hide your deciet).