Deutsch   English   Français   Italiano  
<v2auo0$1ct7o$11@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

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: Can D simulated by H terminate normally? --- Message_ID Provided
Date: Sat, 18 May 2024 15:15:12 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2auo0$1ct7o$11@i2pn2.org>
References: <v0k4jc$laej$1@dont-email.me> <v0l11u$ussl$1@dont-email.me>
 <v0lh24$123q3$1@dont-email.me> <v0lic7$2g492$3@i2pn2.org>
 <v0lkas$12q0o$3@dont-email.me> <v0loq2$2g493$1@i2pn2.org>
 <v0lq7d$14579$2@dont-email.me> <v0ls98$2g492$7@i2pn2.org>
 <v0m29q$166o1$1@dont-email.me> <v0m37e$2gl1e$1@i2pn2.org>
 <v0m3v5$16k3h$1@dont-email.me> <v0m55t$2gl1f$3@i2pn2.org>
 <v0m5sn$172p4$1@dont-email.me> <v0m7em$2gl1f$5@i2pn2.org>
 <v0m7tq$17dpv$1@dont-email.me> <v0m8g9$2gl1e$6@i2pn2.org>
 <v0m978$17k7o$3@dont-email.me> <v0mko6$2hf3s$2@i2pn2.org>
 <v0n59h$1h98e$1@dont-email.me> <v0o037$2j1tu$3@i2pn2.org>
 <v0oc65$1q3aq$3@dont-email.me> <v0p9ts$2ki5r$6@i2pn2.org>
 <v0q1rk$2a3u1$1@dont-email.me> <v0qkti$2m1nf$1@i2pn2.org>
 <v0r4a3$2hb7o$6@dont-email.me> <v0rsbr$2m1nf$6@i2pn2.org>
 <v0segm$2v4oq$1@dont-email.me> <v0t8o9$2p3ri$2@i2pn2.org>
 <v0tpjf$3881i$5@dont-email.me> <v0ulma$2qov4$1@i2pn2.org>
 <v2atgh$2tove$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 18 May 2024 19:15:12 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1471736"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v2atgh$2tove$1@dont-email.me>
Content-Language: en-US
Bytes: 5945
Lines: 130

On 5/18/24 2:54 PM, olcott wrote:
> On 5/1/2024 7:10 PM, Richard Damon wrote:
>> On 5/1/24 12:11 PM, olcott wrote:
>>>> Until you refine your current non-existant definitions of the terms, 
>>>> you have the problem described.
>>>>
>>>
>>> I can't have any idea what you are saying until you fill in
>>> all of the details of your baseless claims.
>>>
>>
>> But you refuse to listen.
>>
>> Remember, YOU are the one saying you are needing to change the 
>> definition from the classical theory, where we have things well defined.
>>
>> YOU have decided that H is just whatever C code you want to write for 
>> it, and D is the input proved. (which doesn't actually match the Linz 
>> or Sipser proof, but fairly close).
>>
> 
> First of all the code template that I am currently referring
> has nothing to do with any decider, it only pertains to a
> simulator where H correctly simulates 1 to ∞ steps of D
> of each H/D pair specified by the following template.

And that is exactly what my H is. It will simulate all of the steps of 
D, the D that call that H, till it reaches the end.


> 
> typedef int (*ptr)();  // ptr is pointer to int function
> 00 int H(ptr x, ptr y);
> 01 int D(ptr x)
> 02 {
> 03   int Halt_Status = H(x, x);
> 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 }
> 
> In the above case 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.

And mine emulates ALL of them to the final return on line 06

> 
> 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.

Yep.

> 
> Execution Trace
> Line 11: main() invokes H(D,D);
> 
> keeps repeating (unless aborted)
> Line 01:
> Line 02:
> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
> 
> Simulation invariant:
> D correctly simulated by H cannot possibly reach past its own line 03.

Proven wrong.

> 
> The key thing to note is that no D correctly simulated by any H of every 
> H/D pair specified by the above template ever reaches its own line 06 
> and halts.

But mine does, so you are just showing you are a liar that doesn't 
understand what he is saying.

> 
>> With THAT set of definitions we have a lot of options that break your 
>> incorrectly assumed results.
>>
> 
> I augmented the definitions since you posted this reply.

Where?

> 
>> The first method has been discussed here by Flibble. While the final 
>> answer he got to doesn't fit the requirements, the first part of the 
>> method DOES show that it is possible for an H to simulate to past line 3.
>>
> 
> It is impossible for D to be correctly simulated by H within the
> above definitions that have H as only a simulator and specify
> exactly what a correct simulation is.

What definitions does it break?


> 
>> THe basic idea is that if H(M,d) finds that its simulation of M(d) get 
>> to a call to H(M,d) then rather that your idea of just saying it will 
>> get stuck and declair the input invalid, since there ARE a number of 
>> possible inputs that there is a "correct" answer that H can give to 
>> match the behavior of the direct execution of M(d), what H does is 
>> fork its simulation into two threads.
>>
> 
> Pure simulator H has no basis to do that. I am stopping here
> you can update this view on this new set of definitions.
> 
> 

So, did you not read that I am primarily talking about the SECOND option?

I guess you don't know how to read and understand basic Englisn.

Yes, the first option, which is largely based on discussions with 
Flibble, chooses to "simulate" calls to H by replacing them with one of 
the two possible results.

But the second option, just goes ahead and simulates H by using code 
that makes the simulation work for the defined C function.