Re: Mike's correction of Joes correct Fred too

On 8/16/2024 9:27 PM, 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".
 

Both or them are incorrect about this.
Joes is saying that Each HHH has one more cycle
and does not realize this is ad infinitum.

>
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,

Anyone that in any way says that DDD emulated by HHH
according to the semantics of the x86 language reaches
its final halt state is wrong one way or another.
*Ben is the only one that got this correctly*

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.

That is all moot when it is the job of HHH to correctly
predict what the behavior of DDD would be if HHH never aborted.

    (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.)
 

HHH aborts as soon as it knows that the cycle would
repeat without aborting.
There is no infinite wait to what the next one does.

-  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!

DDD correctly emulated by HHH according to the semantics
of the x86 language cannot possibly reach it halt state and
halt. Ben understood this and no one else does.

    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.
 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.
  Mike.
 

>
If you keep insisting that I am wrong and fail to explain all
of the details of how I am wrong I will continue to assume that
it is your error of not paying close enough attention.

 You won't understand my explanation above in any case. 

 > The point is > that now you understand that you are misrepresenting my views - SO DON'T

DO IT ANY MORE.
 

I summed up everyone's error in one simple paragraph.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer