Re: Defining a correct halting decidability decider

On 8/4/24 6:57 PM, olcott wrote:

On 8/4/2024 5:31 PM, Richard Damon wrote:

On 8/4/24 6:15 PM, olcott wrote:

On 8/4/2024 5:02 PM, Richard Damon wrote:

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

On 8/4/2024 4:43 PM, Richard Damon wrote:

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

>
It is only allowed to answer 0 when when
(a) The input does not halt
(b) The input has a pathological relationship with the decider.
>
>

>
Which means it is not a property of the INPUT, but the input and the decider.
>

>
It is a property of the input.
(a) The input does
(b) The input has
>

>
But not of JUST the input.
>

>
It is a semantic property of the input.
I don't care if you lie about it.
>

 Nope, because it depends on the decider.