Path: ...!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: Why does Olcott care about simulation, anyway? --- Ben's Review
Date: Mon, 3 Jun 2024 20:56:52 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3look$2uv04$11@i2pn2.org>
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, 4 Jun 2024 00:56:52 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3111940"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v3l16f$5d3$4@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 2876
Lines: 50

On 6/3/24 2:14 PM, olcott wrote:
> 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.

Because 5 and 6 are not what 2 and 3 represent

> 
> DD correctly simulated by HH does have provably
> different behavior than DD(DD) so HH is is not
> allowed to report on the behavior of DD(DD).
> 

Nope, it MUST report on the behavior of DD(DD) as that is what its input 
SPECIFIED.

The machine described by DD *IS* DD
The input to that machine, described by DD *IS* DD

So, the input DD,DD speciefies DD(DD), just like the 2,3 to sum 
specifies 2 + 3.