Re: Defining a correct halting decidability decider

On 8/10/24 7:36 AM, olcott wrote:

On 8/10/2024 6:20 AM, Richard Damon wrote:

On 8/10/24 7:03 AM, olcott wrote:

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
>
>

>
Subjective Requirmeent, thus not a property of JUST the input.
>

Weasel words. DDD does specify non-halting behavior to HHH.
anyone that says otherwise is not telling the truth.
 

Then why does it halt? (When HHH is the decider you claim it to be).
You just don't know what you are talking about
Halting is an OBJECTIVE standard, and as such isn't "to" anything.
HHH, due to the stupiitgy of its programmer, come up with the wrong answer, but that doesn't mean that DDD specified anything but what DDD actually does (and to specify a DDD, you need to specify which HHH is it calling, something that you don't seem to understand).