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.