Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: Defining a correct halting decidability decider
Date: Sun, 11 Aug 2024 09:24:39 +0300
Organization: -
Lines: 117
Message-ID: <v99lf7$25pkm$1@dont-email.me>
References: <v8o47a$3ml4$1@dont-email.me> <0ec454016dab6f6d6dd5580f5d0eea49569293d8@i2pn2.org> <v8oigl$6kik$1@dont-email.me> <6ec9812649b0f4a042edd1e9a1c14b93e7b9a16b@i2pn2.org> <v8ol2g$74lk$1@dont-email.me> <v8v61f$29aqq$1@dont-email.me> <v8vrsb$32fso$5@dont-email.me> <v91r57$3qct4$1@dont-email.me> <v92gpl$p1$4@dont-email.me> <v94lkb$lh2p$1@dont-email.me> <v956lm$o1gt$3@dont-email.me> <v977s1$guti$1@dont-email.me> <v97he3$ilah$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 11 Aug 2024 08:24:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cc6b6595fa10c51424bfd3c050efffdc";
	logging-data="2287254"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19U+IHh5UT4avrly4gjjloz"
User-Agent: Unison/2.2
Cancel-Lock: sha1:MHHoPkF6FHPZBXCY5eRJmkKLATM=
Bytes: 5776

On 2024-08-10 11:03:31 +0000, olcott said:

> 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

Which does not use the stipulation and therefore does not demonstrate
its usefulńess.

That a computation has a pathological relationship to some decider
does not prevent another partial haltdecider from determinig whther
it halts.

-- 
Mikko