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.

But the fact that even with a direct warning that you are misunderstanding, you still go ahead and
repeat your nonsense in the end just becomes FUNNY. :)

Of course, nothing I said above supports your claims for what it is saying. I could challenge you
to justify your claims, but that would just waste everybody's time. You are just intellectually
incapable of discussing this topic. (Not your "fault", you're not being lazy or anything, it's just
how your brain is wired.)


Mike.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Fri, 16 Aug 2024 13:50:10 -0500 schrieb olcott:

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

I don't think that.
If the outer one didn't abort, and the inner did, the whole thing would
halt.

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.

Joke's on you if you don't see your own mistake.

But the fact that even with a direct warning that you are
misunderstanding, you still go ahead and repeat your nonsense in the
end just becomes FUNNY.  :)
Of course, nothing I said above supports your claims for what it is
saying.  I could challenge you to justify your claims, but that would
just waste everybody's time.  You are just intellectually incapable of
discussing this topic.  (Not your "fault", you're not being lazy or
anything, it's just how your brain is wired.)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/24 2:50 PM, 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.

No, the HHH *CAN'T* wait, as it must do what its program says.

It *SHOULD HAVE* waited, as that would have gotten the right answer.

It is just the fact that due to your hopeless intertwining of the
decider and the input program, you CAN NOT unravel that and try to look
at different versions of the decider by change the code of the decider,
but need to make a copy of it with a different name and a different
adddress, but you code for your decider uses techniques that break this
method.

Please try and explain to me exactly how your words did
not correct this error.

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.

But the fact that even with a direct warning that you are
misunderstanding, you still go ahead and repeat your nonsense in the
end just becomes FUNNY.  :)

Of course, nothing I said above supports your claims for what it is
saying.  I could challenge you to justify your claims, but that would
just waste everybody's time.  You are just intellectually incapable of
discussing this topic.  (Not your "fault", you're not being lazy or
anything, it's just how your brain is wired.)


Mike.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 16.aug.2024 om 13:59 schreef olcott:

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.

By cheating, using its Root variable, to change the behaviour of the
input (a HHH that aborts) to the behaviour of a non-input (a HHH that
does not abort).
HHH is coded to abort. Without this Root cheat, the simulated HHH is
also coded to abort. That is the input.
When HHH aborts the simulation of itself, the correct simulated HHH is
only one cycle away from its own abort and halt.

*With abort as soon as you know*
*there is never one more cycle to go*

That is the error in your reasoning. You are cheating with the Root
variable, so that the simulated HHH does not abort. In this way the
simulator changes its input into a non-input.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 16.aug.2024 om 20:50 schreef olcott:

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.

Your English is very poor. I never said such a thing.
I said that HHH, when simulation *itself* fails to reach its end.
I also said that HHH cannot possibly simulate itself correctly.
Now you put words in my mouth about how HHH could be changed to be correct.
I will never make a suggestion about how HHH can be improved to be
correct, because I understand that HHH cannot possibly simulate itself correctly. There is no way to make it correct. It does not help to wait,
it is simply impossible to do it correctly.
Can you repeat what I say? There is no way to make a HHH that can
simulate itself correctly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

In the case of your HHH/DDD, the simulation of DDD /would/ stop running if not aborted - it would
stop in one more cycle. 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.

No way you'll understand any of that I guess...

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 17.aug.2024 om 05:52 schreef olcott:

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.

That is true only because you are cheating with the Root variable, so
that the simulating HHH does not simulated its input, but first changes
the input, by changing the value of Root, so that it simulates a
non-input, the HHH with different behaviour.
We are discussing a HHH that aborts and when the cheating code is
removed, the simulated HHH is also coded to abort, so there is no ad
infinitum.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?


What do you plan to do about the fatal flaw in your design that makes
HHH not a valid decider since it isn't a pure function of its input but
detects via external memory if it is the "root" emulator or not, and
changes its behavior based on that?

What do you plan to do about the fatal flaw that even though its rule
SAYS it is two calls to the same function without a conditional jump
between, it has ignored the conditional jumps it saw in the HHH that DDD called?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)