Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: joes Newsgroups: comp.theory Subject: Re: Mike's correction of Joes correct Fred too Date: Sat, 17 Aug 2024 12:15:30 -0000 (UTC) Organization: i2pn2 (i2pn.org) Message-ID: References: <561f876601b0329c0260bac26f8b6dfb6e28647f@i2pn2.org> <9TOdndS9qv01l137nZ2dnZfqnPWdnZ2d@brightview.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 17 Aug 2024 12:15:30 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2870502"; mail-complaints-to="usenet@i2pn2.org"; posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM"; User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a git.gnome.org/pan2) X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 6488 Lines: 92 Am Fri, 16 Aug 2024 22:58:10 -0500 schrieb olcott: > 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: >>>> 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. Try inverting the Root variable. >> 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. And they change behaviour depending on a static variable. >>> So what you're doing is confusing /design-time/ decisions that /you/ >>> make, with /run-time/ decisions that HHH/HHH2 etc. make.  >> slaps head in sudden understanding!!>  Also, you're calling different >>> things the same name which would be confusing for anybody, but in your >>> case it's worse, because you genuinely don't understand where >>> different objects are involved. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.