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,sci.logic
Subject: Re: Why does Olcott care about simulation, anyway? --- Mikes Review
Date: Tue, 4 Jun 2024 21:47:55 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3og4b$328ec$2@i2pn2.org>
References: <v3j20v$3gm10$2@dont-email.me>
 <J_CdnTaA96jxpcD7nZ2dnZfqnPudnZ2d@brightview.co.uk>
 <v3jei1$3o3a7$1@dont-email.me>
 <0xqdnd8ktrnsc8D7nZ2dnZfqnPqdnZ2d@brightview.co.uk>
 <v3l002$5d3$1@dont-email.me>
 <lZadnYLpbtuB7cP7nZ2dnZfqn_udnZ2d@brightview.co.uk>
 <v3lrm2$4h2j$1@dont-email.me> <v3lsd6$2uv04$17@i2pn2.org>
 <v3ltij$8gjv$3@dont-email.me>
 <7MadnQlevYc8H8P7nZ2dnZfqnPSdnZ2d@brightview.co.uk>
 <v3m0m0$8r46$2@dont-email.me> <v3m3af$2uv04$19@i2pn2.org>
 <v3nina$gatu$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 5 Jun 2024 01:47:55 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3219916"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v3nina$gatu$5@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 3726
Lines: 54

On 6/4/24 1:26 PM, olcott wrote:
> On 6/3/2024 10:57 PM, Richard Damon wrote:
>> On 6/3/24 11:12 PM, olcott wrote:
>>> On 6/3/2024 9:57 PM, Mike Terry wrote:
>>>> On 04/06/2024 03:18, olcott wrote:
>>>>> On 6/3/2024 8:59 PM, Richard Damon wrote:
>>>>>> On 6/3/24 9:46 PM, olcott wrote:
>>>>>>> On 6/3/2024 8:38 PM, Mike Terry wrote:
>>>
>>>>>>>> An execution trace that is produced by a program that is 
>>>>>>>> incorrect /proves/ nothing whatsoever. I don't need to look at 
>>>>>>>> your proof, as I was commenting on the value of your program 
>>>>>>>> output AS PROOF.
>>>>>>>>
>>>>>>>
>>>>>>> I provided the execution trace that HH derives
>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT*
>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT*
>>>>>>> *AND THE X86 SOURCE-CODE OF DD THAT PROVES THIS TRACE IS CORRECT*
>>>>>>
>>>>>> Then why did the trace not follow the call to H?
>>>>>>
>>>>>
>>>>> HH(DD,DD) the trace does follow the call to HH(DD,DD)
>>>>> and fully simulates itself simulating DD.
>>>>
>>>> Yes HH does simulate the call to HH(DD,DD) and certain instructions 
>>>> within HH, although because you filter those trace entries out, 
>>>> nobody can check that.
>>>>
>>>> The point is it simulates THE WRONG INSTRUCTIONS within HH as 
>>>> discussed in other posts.
>>>>
>>>
>>> I conclusively proved that HH correctly simulated the instructions of
>>> DD and I also proved that the simulated HH also correctly simulated the
>>> instructions of DD by the fact that the provided execution traces by 
>>> both the outer and the inner nested simulations exactly matched the 
>>> behavior that the x86 source code of D specifies, line-by-line.
>>
>> Nope, not that you have ever published, at least not by your current 
>> definition, as you have never to my knowledge published any trace that 
>> showed the x86 insturctions of HH (or H).
>>
> 
> Published hundreds of times here any other places,
> now publishing it again right here:
> 
> On 6/4/2024 11:28 AM, olcott wrote:
> [Proof that executed HH(DD,DD) and simulated HH(DD,DD)
>   simulate DD correctly -- Mike Terry]
> 

But based on the WRONG definition of "Correct" to be able to talk about 
the input being non-halting, so just "double speak", and essentially a LIE.