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: Halting Problem is wrong two different ways
Date: Thu, 6 Jun 2024 18:09:15 +0300
Organization: -
Lines: 96
Message-ID: <v3sjer$1i8m9$1@dont-email.me>
References: <v3j20v$3gm10$2@dont-email.me> <J_CdnTaA96jxpcD7nZ2dnZfqnPudnZ2d@brightview.co.uk> <87h6eamkgf.fsf@bsb.me.uk> <v3kcdj$3stk9$1@dont-email.me> <v3kjs9$3u7ng$1@dont-email.me> <v3l16f$5d3$4@dont-email.me> <v3mj84$bq2d$1@dont-email.me> <v3njiv$gatu$9@dont-email.me> <v3p37n$sb6j$1@dont-email.me> <v3poj0$v133$6@dont-email.me> <v3rvri$1ervp$1@dont-email.me> <v3sene$1gra7$10@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 06 Jun 2024 17:09:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2c3efa56d70eb2a475af8055aec55f19";
	logging-data="1647305"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19D2sqVavA8m9XwhnAqYNuJ"
User-Agent: Unison/2.2
Cancel-Lock: sha1:xSOC6C+bJ7hOrSvd8ETV7j5l/7Q=
Bytes: 5191

On 2024-06-06 13:48:29 +0000, olcott said:

> On 6/6/2024 4:34 AM, Mikko wrote:
>> On 2024-06-05 13:18:24 +0000, olcott said:
>> 
>>> On 6/5/2024 2:13 AM, Mikko wrote:
>>>> On 2024-06-04 17:40:47 +0000, olcott said:
>>>> 
>>>>> On 6/4/2024 3:28 AM, Mikko wrote:
>>>>>> On 2024-06-03 18:14:39 +0000, olcott said:
>>>>>> 
>>>>>>> On 6/3/2024 9:27 AM, Mikko wrote:
>>>>>>>> On 2024-06-03 12:20:01 +0000, olcott said:
>>>>>>>> 
>>>>>>>>> On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>>> 
>>>>>>>>>>> PO's D(D) halts, as illustrated in various traces that have been posted here.
>>>>>>>>>>> PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various traces.
>>>>>>>>>>> i.e. exactly as the Linz proof claims.  PO has acknowledged both these
>>>>>>>>>>> results.  Same for the HH/DD variants.
>>>>>>>>>>> 
>>>>>>>>>>> You might imagine that's the end of the matter - PO failed.  :)
>>>>>>>>>>> 
>>>>>>>>>>> That's right, but PO just carries on anyway!
>>>>>>>>>> 
>>>>>>>>>> He has quite explicitly stated that false (0) is the correct result for
>>>>>>>>>> H(D,D) "even though D(D) halts".  I am mystified why anyone continues to
>>>>>>>>>> discuss the matter until he equally explicitly repudiates that claim.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>>>> accept or reject state.
>>>>>>>> 
>>>>>>>> That does not restrict what a problem statement can specify.
>>>>>>>> If the computed mapping differs from the specified one the
>>>>>>>> decider does not solve the problem.
>>>>>>> 
>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>> sum(2,3) cannot return the sum of 5 + 6.
>>>>>> 
>>>>>> That does not restrict what a problem statement can specify.
>>>>>> If the mapping computed by sum differs from the specified one
>>>>>> the program sum does not solve the problem.
>>>>>> 
>>>>> 
>>>>> On 6/3/2024 9:53 PM, Richard Damon wrote:
>>>>>  > Because you keep on mentioning about DD Halting,
>>>>>  > which IS about the direct execution of DD
>>>>> 
>>>>> Only when one contradicts the definition of a decider that must
>>>>> compute the mapping FROM ITS INPUTS BASED ON THE ACTUAL BEHAVIOR
>>>>> OF THESE INPUTS (as measured by DD correctly simulated by HH).
>>>>> 
>>>>> When we go ahead and contradict this definition then the
>>>>> *HALTING PROBLEM IS STILL WRONG IN A DIFFERENT WAY*
>>>>> 
>>>>> When D is defined to do the opposite of whatever yes/no
>>>>> an answer that H provides then the counter-example input
>>>>> is precisely isomorphic to the question:
>>>>> Is this sentence: "This sentence is not true." true or false?
>>>>> Thus that question and the HP question are both incorrect
>>>>> because both yes and no are the wrong answer.
>>>>> 
>>>>> The theory of computation may be ignorant of the details of
>>>>> how the context of who is asked a question changes the meaning
>>>>> of this question, none-the-less this cannot be ignored.
>>>>> It is and remains incorrect for the theory of computation
>>>>> to ignore this.
>>>> 
>>>> Nice to see that you don't disagree with my observation that
>>>> your statement
>>>> 
>>>>>>>>> Deciders only compute the mapping *from their inputs* to their own
>>>>>>>>> accept or reject state.
>>>> 
>>>> does not restrict what a problem statement can specify.
>>>> 
>>> 
>>> Sure it does.
>>> int sum(int x, int y) { return x + y; }
>>> sum(3,4) cannot correctly return the sum of 5 + 6.
>> 
>> That does not restrict what the problem statement can specify.
>> 
> 
> When someone tries to prove that sum(3,4) is incorrect on the
> basis that it cannot correctly provide the sum of 5 + 6, then
> they are wrong.

Meybe, maybe not. That depends on the requirements. In any case,
that does not restrict what the problem statement can specify.

-- 
Mikko