Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Defining a correct halting decidability decider
Date: Fri, 9 Aug 2024 19:46:24 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <64f208b8dc9bb97781f1c0eee8bfb25dc9f0b68c@i2pn2.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 9 Aug 2024 23:46:24 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2032646"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v956lm$o1gt$3@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 5686
Lines: 108

On 8/9/24 9:47 AM, olcott wrote:
> 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.
> 

But, to be a property of an input, it must depend on ONLY that input, 
that that means that if ANY decider can properly decide on 
"has_eaten_lunch" for that input, it is decidable, since either M0 (the 
machine that answer 0 for all inputs) or M1 (the machine that answers 1 
for all inputs) for THAT input (the particular DDD/HHH pairing that 
wants to call the input undecidable) the input IS decidable, it is just 
that THAT HHH get the answer wrong for THAT input.

Remember, the input is a FULL PROGRAM, and thus is the DDD "template" 
paired with a specific HHH to get a particular DDD program. (Giving the 
two the same name is just part of your attempt to hide your deciet).