Re: Defining a correct halting decidability decider

Liste des GroupesRevenir à theory 
Sujet : Re: Defining a correct halting decidability decider
De : mikko.levanto (at) *nospam* iki.fi (Mikko)
Groupes : comp.theory
Date : 08. Aug 2024, 09:12:39
Autres entêtes
Organisation : -
Message-ID : <v91r57$3qct4$1@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : Unison/2.2
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.
--
Mikko

Date Sujet#  Auteur
4 Aug 24 * Defining a correct halt decider67olcott
4 Aug 24 +* Re: Defining a correct halt decider45Richard Damon
4 Aug 24 i`* Re: Defining a correct halting decidability decider44olcott
4 Aug 24 i `* Re: Defining a correct halting decidability decider43Richard Damon
4 Aug 24 i  `* Re: Defining a correct halting decidability decider42olcott
4 Aug 24 i   +* Re: Defining a correct halting decidability decider20Richard Damon
4 Aug 24 i   i`* Re: Defining a correct halting decidability decider19olcott
4 Aug 24 i   i `* Re: Defining a correct halting decidability decider18Richard Damon
4 Aug 24 i   i  `* Re: Defining a correct halting decidability decider17olcott
5 Aug 24 i   i   `* Re: Defining a correct halting decidability decider16Richard Damon
5 Aug 24 i   i    `* Re: Defining a correct halting decidability decider15olcott
5 Aug 24 i   i     `* Re: Defining a correct halting decidability decider14Richard Damon
5 Aug 24 i   i      `* Re: Defining a correct halting decidability decider13olcott
5 Aug 24 i   i       `* Re: Defining a correct halting decidability decider12Richard Damon
5 Aug 24 i   i        `* Re: Defining a correct halting decidability decider11olcott
5 Aug 24 i   i         `* Re: Defining a correct halting decidability decider10Richard Damon
5 Aug 24 i   i          `* You still seem too dishonest to admit that DDD correctly emulated by any HHH cannot possibly reach its own ,"return" instruction9olcott
5 Aug 24 i   i           `* Re: You still seem too dishonest to admit that DDD correctly emulated by any HHH cannot possibly reach its own ,"return" instruction8Richard Damon
5 Aug 24 i   i            `* Re: You still seem too dishonest to admit that DDD correctly emulated by any HHH cannot possibly reach its own ,"return" instruction7olcott
5 Aug 24 i   i             `* Re: You still seem too dishonest to admit that DDD correctly emulated by any HHH cannot possibly reach its own ,"return" instruction6Richard Damon
5 Aug 24 i   i              `* Re: You still seem too dishonest to admit that DDD correctly emulated by any HHH cannot possibly reach its own ,"return" instruction5olcott
5 Aug 24 i   i               `* Re: You still seem too dishonest to admit that DDD correctly emulated by any HHH cannot possibly reach its own ,"return" instruction4Richard Damon
5 Aug 24 i   i                `* Re: You still seem too dishonest to admit that DDD correctly emulated by any HHH cannot possibly reach its own ,"return" instruction3wij
5 Aug 24 i   i                 `* Re: You still seem too dishonest to admit that DDD correctly emulated by any HHH cannot possibly reach its own ,"return" instruction2olcott
6 Aug 24 i   i                  `- Re: Olcott still seems too dishonest to admit that his HHH doesn't correctly emulate DDD1Richard Damon
7 Aug 24 i   `* Re: Defining a correct halting decidability decider21Mikko
7 Aug 24 i    `* Re: Defining a correct halting decidability decider20olcott
8 Aug 24 i     +- Re: Defining a correct halting decidability decider (Which isn't a valid criteria for a decider)1Richard Damon
8 Aug 24 i     `* Re: Defining a correct halting decidability decider18Mikko
8 Aug 24 i      `* Re: Defining a correct halting decidability decider17olcott
8 Aug 24 i       +* Re: Defining a correct halting decidability decider4Python
8 Aug 24 i       i`* Re: Defining a correct halting decidability decider3olcott
9 Aug 24 i       i +- Re: Defining a correct halting decidability decider1Richard Damon
9 Aug 24 i       i `- Re: Defining a correct halting decidability decider1Python
9 Aug 24 i       +- Re: Defining a correct halting decidability decider1Richard Damon
9 Aug 24 i       `* Re: Defining a correct halting decidability decider11Mikko
9 Aug 24 i        `* Re: Defining a correct halting decidability decider10olcott
10 Aug 24 i         +- Re: Defining a correct halting decidability decider1Richard Damon
10 Aug 24 i         `* Re: Defining a correct halting decidability decider8Mikko
10 Aug 24 i          `* Re: Defining a correct halting decidability decider7olcott
10 Aug 24 i           +* Re: Defining a correct halting decidability decider3Richard Damon
10 Aug 24 i           i`* Re: Defining a correct halting decidability decider2olcott
10 Aug 24 i           i `- Re: Defining a correct halting decidability decider1Richard Damon
11 Aug 24 i           `* Re: Defining a correct halting decidability decider3Mikko
11 Aug 24 i            `* Re: Defining a correct halting decidability decider2olcott
11 Aug 24 i             `- Re: Defining a correct halting decidability decider1Richard Damon
5 Aug 24 `* Re: Defining a correct halt decider21Mikko
5 Aug 24  `* I call it a halting decidability decider20olcott
5 Aug 24   +* Re: I call it a halting decidability decider14Python
5 Aug 24   i`* Re: I call it a halting decidability decider13olcott
6 Aug 24   i +* Re: I call it a halting decidability decider, and thus isn't actually a computability decider.5Richard Damon
6 Aug 24   i i`* Re: I call it a halting decidability decider, and thus isn't actually a computability decider.4olcott
6 Aug 24   i i `* Re: I call it a halting decidability decider, and thus isn't actually a computability decider.3Richard Damon
6 Aug 24   i i  `* Re: I call it a halting decidability decider, and thus isn't actually a computability decider.2olcott
6 Aug 24   i i   `- Re: I call it a halting decidability decider, and thus isn't actually a computability decider.1Richard Damon
7 Aug 24   i `* Re: I call it a halting decidability decider7Mikko
7 Aug 24   i  `* HHH decides a non-trivial semantic property of its input6olcott
8 Aug 24   i   +- Re: HHH decides a trivial semantic non-property of its input1Richard Damon
8 Aug 24   i   +* Re: HHH decides a non-trivial semantic property of its input3Mikko
8 Aug 24   i   i`* Re: HHH decides a non-trivial semantic property of its input2olcott
9 Aug 24   i   i `- Re: HHH decides a non-trivial semantic property of its input1Richard Damon
8 Aug 24   i   `- Re: HHH decides a trivial non-semantic non-property of its input1Richard Damon
6 Aug 24   +- Re: I call it a halting decidability decider, and thus doesn't say anything about the halting problem1Richard Damon
7 Aug 24   `* Re: I call it a halting decidability decider4Mikko
7 Aug 24    `* Re: I call it a halting decidability decider3olcott
8 Aug 24     +- Re: I call it a halting decidability decider1Richard Damon
8 Aug 24     `- Re: I call it a halting decidability decider1Mikko

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal