| Deutsch English Français Italiano |
|
<4a248675fef8b40bdcff6abc4286a62e4149e3e8@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 Subject: Re: Mike's correction of Joes correct Fred too Date: Sat, 17 Aug 2024 10:10:20 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <4a248675fef8b40bdcff6abc4286a62e4149e3e8@i2pn2.org> References: <v9gv4k$4sc4$1@dont-email.me> <561f876601b0329c0260bac26f8b6dfb6e28647f@i2pn2.org> <v9h5af$9jn6$1@dont-email.me> <bdfcf881b9a9ce7e2bc197339d14a01beae1116d@i2pn2.org> <XYucnXqdgeWiVSH7nZ2dnZfqn_adnZ2d@brightview.co.uk> <b8a96bbfe0516cf99b6f38c23fb4eccc3810ee7e@i2pn2.org> <v9krc5$uqhs$1@dont-email.me> <v9l7hf$vao1$3@dont-email.me> <v9laed$113gd$2@dont-email.me> <EbecnaOe1ajC1yP7nZ2dnZfqn_idnZ2d@brightview.co.uk> <v9llh9$12l6c$2@dont-email.me> <v9mt9h$1bdeu$3@dont-email.me> <v9nev6$1dvef$2@dont-email.me> <TqucndEmmvrpASL7nZ2dnZfqnPGdnZ2d@brightview.co.uk> <v9o712$1h5u4$2@dont-email.me> <9TOdndS9qv01l137nZ2dnZfqnPWdnZ2d@brightview.co.uk> <BoWdnTmikd8ojV37nZ2dnZfqn_adnZ2d@brightview.co.uk> <v9p74i$1p6bp$3@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 17 Aug 2024 14:10:20 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2897735"; 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: <v9p74i$1p6bp$3@dont-email.me> Content-Language: en-US Bytes: 10044 Lines: 200 On 8/16/24 11:58 PM, olcott wrote: > On 8/16/2024 9:53 PM, Mike Terry wrote: >> On 17/08/2024 03:27, Mike Terry wrote: >>> On 16/08/2024 19:50, olcott wrote: >>>> On 8/16/2024 1:37 PM, Mike Terry wrote: >>>>> On 16/08/2024 12:59, olcott wrote: >>>>>> On 8/16/2024 1:57 AM, Fred. Zwarts wrote: >>>>>>> Op 15.aug.2024 om 21:39 schreef olcott: >>>>>>> >>>>>>> It is clear that olcott does not really read what I write. (Or is >>>>>>> very short of memory.) >>>>>>> I never said such a thing. >>>>>>> I repeatedly told that the >>>>>> >>>>>> *YOUR MISTAKE* >>>>>>> simulating HHH aborted when the simulated HHH had only one cycle >>>>>>> to go. >>>>>> That is WRONG. The outermost directly executed HHH aborts >>>>>> as soon as it has seen enough of the emulated execution >>>>>> trace to correctly predict that an unlimited execution >>>>>> would never stop running. >>>>>> >>>>>> *With abort as soon as you know* >>>>>> *there is never one more cycle to go* >>>>>> >>>>>> *MIKES CORRECTION OF YOUR MISTAKE* >>>>>> On 8/14/2024 10:07 AM, Mike Terry wrote: >>>>>> > On 14/08/2024 08:43, joes wrote: >>>>>> >> HHH simulates DDD enter the matrix >>>>>> >> DDD calls HHH(DDD) Fred: could be eliminated >>>>>> >> HHH simulates DDD second level >>>>>> >> DDD calls HHH(DDD) recursion detected >>>>>> >> HHH aborts, returns outside interference >>>>>> >> DDD halts voila >>>>>> >> HHH halts >>>>>> > >>>>>> > You're misunderstanding the scenario? If your simulated >>>>>> > HHH aborts its simulation [line 5 above], >>>>>> >>>>>> *THIS PART RIGHT HERE* >>>>>> > then the outer level H would have aborted its >>>>>> > identical simulation earlier. You know that, right? >>>>>> >>>>>> > [It's what people have been discussing >>>>>> > here endlessly for the last few months! :) ] >>>>>> > >>>>>> > So your trace is impossible... >>>>>> > >>>>> >>>>> I supposed that I should be annoyed that you deliberately ignore my >>>>> request to stop misrepresting my views and opinions. You /know/ I >>>>> don't agree with how you're misusing my words - but you do it anyway. >>>>> >>>> >>>> Both Joes and Fred seem to think that every HHH can wait for >>>> the next one to abort and one of them will still eventually >>>> abort. >>> >>> Fred above says that when HHH aborts simulated HHH, the simulation >>> has only one more cycle to go before it terminates. *HE DOES NOT SAY >>> THAT HHH MUST WAIT ONE MORE CYCLE BEFORE ABORTING*. And I'm pretty >>> sure he doesn't think what you think he "seems to think". >>> >>>> >>>> Please try and explain to me exactly how your words did >>>> not correct this error. >>> >>> Well first off - what you're challenging me to explain isn't >>> something that either Fred or Joes were saying, so if you believed my >>> words "corrected that error" then you had no justification in quoting >>> me, because Fred and Joes /weren't making that error/. This is just >>> you not following the thread of conversation, or not understanding >>> the meaning of what Fred/Joes are saying to you. It would be like >>> you saying "HHH correctly decides DDD" and I post a reply sending you >>> to an atheist web site. When challenged I say "I thought you believed >>> in God which is a mistake, so sending you to the web site would >>> address that error." [You see, it doesn't hang together...] >>> >>> Secondly, my quote above is pointing out why Joes' counterexample >>> doesn't work. It says that the /simulation/ of DDD by HHH never >>> reaches DDD's final return e.g. because HHH *ABORTS* its simulation >>> before that happens. *NOTHING IN THERE ABOUT HHH WAITING ONE MORE >>> CYCLE BEFORE ABORTING*. >>> >>> For the record, so you're not tempted to continue misrepresnting me: >>> >>> - HHH /does/ abort its simulation of DDD before the simulation >>> reaches DDD's final ret. >>> (I'll go with Fred's "one cycle too early", for a suitable >>> understanding of "cycle". >>> The cycles aren't machine instructions, and each extra cycle we >>> consider takes >>> exponentially more machine instructions to simulate... That's >>> all ok.) >>> >>> - From a /design/ perspective, coding a new HHH2 to be like HHH but >>> waiting one more cycle >>> achieves nothing because then its corresponding new DDD2 will >>> also run for one more cycle >>> before halting, compared with DDD. So it remains the case that >>> HHH2 aborts DDD2 one cycle >>> before it will halt! >>> So such a /design/ change does not help you. >>> *I am not suggesting you redesign HHH to wait more cycles* >>> *Neither Fred, Joes nor I believe that HHH waiting more cycles >>> will fix* >>> *your /design/ problem*. [No design for HHH will work, as Linz >>> proves. Claiming >>> one of your design decisions is "correct" because an alterntive >>> fails makes no sense.] >>> >>> - From a /run time/ perspective, yes, creating HHH2 to wait one more >>> cycle enables it >>> to correctly handle previous input DDD! It will no longer abort >>> too soon, so it will see >>> DDD return and correctly decide "halts". But Linz/Sipser don't >>> contradict this - >>> they both argue that HHH2 will decide /DDD2/ (not DDD) incorrectly. >> >> Also I should have made clear here that if we are talking "Sipser >> quote" about HHH simulating input DDD, then Sipser's wording is "its >> simulated D would never stop running unless aborted". >> > > That is my work that Professor Sipser approved. > DDD emulated by HHH never stops running unless aborted. > >> In the case of your HHH/DDD, the simulation of DDD /would/ stop >> running if not aborted - it would stop in one more cycle. > > OK so you too are confused. You understand the code > download it and get it to do what you said. > >> This is demonstrated with HHH2 above, or with a "never abort" UTM. >> THAT IS WHAT SIPSER MEANS BY HIS AGREEMENT TO THAT WORDING. I.e. >> Sipser is talking "run-time" behaviour, not design-time change >> behaviour. That's how I see it in any case. >> >> So no way Sipser would become confused by your design-time coding >> change which switches looking at input DDD to suddenly looking at >> DDD2 or DDD3 or DDDanythingelse. His statement applies specifically >> to input DDD. >> > > > All DDD are at the exact same machine address. So, all the HHH are put at the same addrees to, and DDD includes the code for that HHH by reference. Unless all HHH are the same, not all DDD are the same. > >> No way you'll understand any of that I guess... >> > > I created the system. I do understand my own system. Nope, seems not. Why can't you get a version of HHH that generates a trace listing of JUST what HHH sees in its simulation? ========== REMAINDER OF ARTICLE TRUNCATED ==========