Path: ...!news.misty.com!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: Can you see that D correctly simulated by H remains stuck in
 recursive simulation?
Date: Fri, 24 May 2024 13:31:00 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2qisk$1vblq$4@i2pn2.org>
References: <v2nsvh$1rd65$2@dont-email.me> <v2pl4r$28ohs$1@dont-email.me>
 <v2qi1g$2dpfr$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 May 2024 17:31:00 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2076346"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v2qi1g$2dpfr$7@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3795
Lines: 71

On 5/24/24 1:16 PM, olcott wrote:
> On 5/24/2024 4:03 AM, Mikko wrote:
>> On 2024-05-23 17:04:49 +0000, olcott said:
>>
>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>> 00       int H(ptr p, ptr i);
>>> 01       int D(ptr p)
>>> 02       {
>>> 03         int Halt_Status = H(p, p);
>>> 04         if (Halt_Status)
>>> 05           HERE: goto HERE;
>>> 06         return Halt_Status;
>>> 07       }
>>> 08
>>> 09       int main()
>>> 10       {
>>> 11         H(D,D);
>>> 12         return 0;
>>> 13       }
>>>
>>> The above template refers to an infinite set of H/D pairs where D is
>>> correctly simulated by pure function H. This was done because many
>>> reviewers used the shell game ploy to endlessly switch which H/D pair
>>> was being referred to.
>>>
>>> *Correct Simulation Defined*
>>>     This is provided because every reviewer had a different notion of
>>>     correct simulation that diverges from this notion.
>>>
>>>     A simulator is an x86 emulator that correctly emulates at least one
>>>     of the x86 instructions of D in the order specified by the x86
>>>     instructions of D.
>>>
>>>     This may include correctly emulating the x86 instructions of H in
>>>     the order specified by the x86 instructions of H thus calling H(D,D)
>>>     in recursive simulation.
>>>
>>> *Execution Trace*
>>>     Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, 
>>> and 03
>>>     of D. This invokes H(D,D) again to repeat the process in endless
>>>     recursive simulation.
>>
>> One can see that D is never stuch in recursive simulation unless H is.
> 
> Counter-factual, please try again.

No, it is a PROVEN fact, as oposed your your unsound logic that tries to 
disprove it.

How can D(D) be stuck in "Recursive Simulation" unless the H(D,D) it 
calls is.

Since you admit and require that H be a "pure funciton" ALL calls to 
H(D,D) will act the same, and thus if H(D,D) returns an answer, D(D) 
must get that exact same answer from the H that it calls.

The fact that H can not simulate its input to that point is meaningless, 
and you true to use your lies to present the logic that you find 
convincing but we see the lies in it.

> 
>> Whether H is cannot be seen has the details of H are not shown. Even
>> if they were H must, in order to simulate any x86 execution, be so
>> big and complicated that essential aspect may be hard to see; depending,
>> of course, on how the code is organized.
>>
> 
> We simply assume that H is the C equivalent of a UTM that
> stops simulating at some point and returns the meaningless 56.
>