Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
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: <f3bcff98943a3951cb7c79feadf774aafe4fb3e8@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
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.  <Duh! PO
>>> 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.