Re: Mike's correction of Joes correct Fred too

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.