Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.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: Why does Olcott care about simulation, anyway? --- Ben's Review
Date: Tue, 4 Jun 2024 11:28:52 +0300
Organization: -
Lines: 39
Message-ID: <v3mj84$bq2d$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 04 Jun 2024 10:28:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dce6fda481f9f7f7aa278ce7b31b5172";
	logging-data="387149"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX198aE3pMn2VBDFtTVVVMx9/"
User-Agent: Unison/2.2
Cancel-Lock: sha1:nH7D4eZx/N4jBVnrtBrCcuQg99s=
Bytes: 2621

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.

-- 
Mikko