Path: ...!news.mixmin.net!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 12:34:42 +0300
Organization: -
Lines: 85
Message-ID: <v3rvri$1ervp$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 06 Jun 2024 11:34:43 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dc169db811f81de646344835dad2e58d";
	logging-data="1535993"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/NaC17HBDxmUB7RZAwHhYU"
User-Agent: Unison/2.2
Cancel-Lock: sha1:VTpLnURJ0zUlXzdmipgBzfHd7Ts=
Bytes: 4605

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.

-- 
Mikko