Re: Defining a correct halting decidability decider

On 8/4/24 5:05 PM, olcott wrote:

On 8/4/2024 3:14 PM, Richard Damon wrote:

On 8/4/24 3:33 PM, olcott wrote:

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

>
Which isn't halt deciding, so you are just admitting you have been lying about working on the Halting Problem.
>

 It does seem to refute Rice.
 

Nope, because your criteria in not a semantic property of the INPUT (or it is trivial, as 0 is always a correct answer).
If some deciders can answer 0 for this input, because THEY can't decide it, but others need to answer 1 because they CAN decide it as halting, it isn't a property of the input, but of the input/decider pair, which Rice doesn't talk about.
Again, you are just proving your ignorance of what you are talking about.