Re: Defining a correct halting decidability decider

Liste des GroupesRevenir à theory 
Sujet : Re: Defining a correct halting decidability decider
De : abc (at) *nospam* def.com (olcott)
Groupes : comp.theory
Date : 04. Aug 2024, 20:33:36
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v8ol2g$74lk$1@dont-email.me>
References : 1 2 3 4
User-Agent : Mozilla Thunderbird
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
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Date Sujet#  Auteur
4 Jul 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal