Op 27.jun.2025 om 16:08 schreef olcott:

On 6/27/2025 2:59 AM, Fred. Zwarts wrote:

Op 27.jun.2025 om 06:26 schreef olcott:

On 6/26/2025 3:46 AM, Fred. Zwarts wrote:

Op 25.jun.2025 om 17:42 schreef olcott:

On 6/25/2025 2:38 AM, Mikko wrote:

On 2025-06-24 14:39:52 +0000, olcott said:

*ChatGPT and I agree that*
The directly executed DDD() is merely the first step of
otherwise infinitely recursive emulation that is terminated
at its second step.

No matter who agrees, the directly executed DDD is mote than
merely the first step of otherwise infinitely recursive
emulation that is terminated at its second step. Not much
more but anyway. After the return of HHH(DDD) there is the
return from DDD which is the last thing DDD does before its
termination.

*HHH(DDD) the input to HHH specifies non-terminating behavior*
The fact that DDD() itself halts does not contradict that
because the directly executing DDD() cannot possibly be an
input to HHH in the Turing machine model of computation,
thus is outside of the domain of HHH.

Why repeating claims that have been proven incorrect.
The input to HHH is a pointer to code, that includes the code of
HHH, including the code to abort and halt. Therefore, it specifies a
halting program.

*No, you are using an incorrect measure*
*I have addressed this too many times*

... with invalid measures.
The measure is not whether the simulator can do its job, the measure
is what the input specifies.

DDD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state *No matter what HHH does*
Therefore the input to HHH(DD) unequivocally
specifies non-halting behavior.

If the simulator cannot analyse this specification,

*It has been doing this correctly for several years*

Another invalid claim without evidence.
Bugs in your program have been pointed out to you for many years, but
you keep dreaming without taking notice of the facts.
The facts are that HHH does not count the conditional branch
instructions, when it is simulating itself. This makes HHH blind for the specification in the input of the abort done by HHH and the halting
behaviour of the program.
That HHH is blind for this part of the specification does not change the specification.
HHH behaves just like Olcott himself: close your eyes and pretend that
things you do not see do not exist. Very childish.

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

On 6/28/25 9:08 AM, olcott wrote:

On 6/28/2025 3:57 AM, Fred. Zwarts wrote:

Op 27.jun.2025 om 16:08 schreef olcott:

On 6/27/2025 2:59 AM, Fred. Zwarts wrote:

Op 27.jun.2025 om 06:26 schreef olcott:

On 6/26/2025 3:46 AM, Fred. Zwarts wrote:

Op 25.jun.2025 om 17:42 schreef olcott:

On 6/25/2025 2:38 AM, Mikko wrote:

On 2025-06-24 14:39:52 +0000, olcott said:

*ChatGPT and I agree that*
The directly executed DDD() is merely the first step of
otherwise infinitely recursive emulation that is terminated
at its second step.

No matter who agrees, the directly executed DDD is mote than
merely the first step of otherwise infinitely recursive
emulation that is terminated at its second step. Not much
more but anyway. After the return of HHH(DDD) there is the
return from DDD which is the last thing DDD does before its
termination.

*HHH(DDD) the input to HHH specifies non-terminating behavior*
The fact that DDD() itself halts does not contradict that
because the directly executing DDD() cannot possibly be an
input to HHH in the Turing machine model of computation,
thus is outside of the domain of HHH.

Why repeating claims that have been proven incorrect.
The input to HHH is a pointer to code, that includes the code of
HHH, including the code to abort and halt. Therefore, it specifies >>>>>> a halting program.

*No, you are using an incorrect measure*
*I have addressed this too many times*

... with invalid measures.
The measure is not whether the simulator can do its job, the measure
is what the input specifies.

DDD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state *No matter what HHH does*
Therefore the input to HHH(DD) unequivocally
specifies non-halting behavior.

If the simulator cannot analyse this specification,

*It has been doing this correctly for several years*

Another invalid claim without evidence.
Bugs in your program have been pointed out to you for many years, but
you keep dreaming without taking notice of the facts.
The facts are that HHH does not count the conditional branch
instructions, when it is simulating itself. This makes HHH blind for
the specification in the input of the abort done by HHH and the
halting behaviour of the program.

HHH reaches its "return" instruction final halt state.

DDD correctly simulated by HHH cannot possibly reach
its own final halt state no matter what HHH does.

But since you just said that HHH DOES reach its final state, it can't do
a correct simulation, and thus you "argument" is just a LIE.

ANY DDD built from an HHH that reaches its final state will, when
correctly simulated or executed, also reach its final state.

PERIOD, PROVEN.

You are getting confused over what is being measured.
If we were measuring whether or not HHH halts then
you would be correct. *We are not measuring that*

No, YOU are, as you don't understand that you have more than one DDD
that you are talking about, or your DDD just can't be correctly simulatd.

Since, to be a program and correctly simulatable, it must include the
HHH that it was built to call, EVERY HHH, since your definition is that
HHH gets the DDD built on it, gets a different HHH.

This means that your logic that claims all DDD to be the same is a LIE,
as that would require that all your HHH be the same, but you NEED (to
make your argument) different HHHs.

That HHH is blind for this part of the specification does not change
the specification.
HHH behaves just like Olcott himself: close your eyes and pretend that
things you do not see do not exist. Very childish.

Sorry, all yoiu are doing is proving that you are just mentally
deficient, either you are a pathological liar that doesn't care about
your lies, or are so mentally deficient that you can't learn the very
basics of what you are talking about.

This is your eternal reputation, that YOU have made for yourself by your
own words.

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

Op 28.jun.2025 om 15:08 schreef olcott:

On 6/28/2025 3:57 AM, Fred. Zwarts wrote:

Op 27.jun.2025 om 16:08 schreef olcott:

On 6/27/2025 2:59 AM, Fred. Zwarts wrote:

Op 27.jun.2025 om 06:26 schreef olcott:

On 6/26/2025 3:46 AM, Fred. Zwarts wrote:

Op 25.jun.2025 om 17:42 schreef olcott:

On 6/25/2025 2:38 AM, Mikko wrote:

On 2025-06-24 14:39:52 +0000, olcott said:

*ChatGPT and I agree that*
The directly executed DDD() is merely the first step of
otherwise infinitely recursive emulation that is terminated
at its second step.

No matter who agrees, the directly executed DDD is mote than
merely the first step of otherwise infinitely recursive
emulation that is terminated at its second step. Not much
more but anyway. After the return of HHH(DDD) there is the
return from DDD which is the last thing DDD does before its
termination.

*HHH(DDD) the input to HHH specifies non-terminating behavior*
The fact that DDD() itself halts does not contradict that
because the directly executing DDD() cannot possibly be an
input to HHH in the Turing machine model of computation,
thus is outside of the domain of HHH.

Why repeating claims that have been proven incorrect.
The input to HHH is a pointer to code, that includes the code of
HHH, including the code to abort and halt. Therefore, it specifies >>>>>> a halting program.

*No, you are using an incorrect measure*
*I have addressed this too many times*

... with invalid measures.
The measure is not whether the simulator can do its job, the measure
is what the input specifies.

DDD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state *No matter what HHH does*
Therefore the input to HHH(DD) unequivocally
specifies non-halting behavior.

If the simulator cannot analyse this specification,

*It has been doing this correctly for several years*

Another invalid claim without evidence.
Bugs in your program have been pointed out to you for many years, but
you keep dreaming without taking notice of the facts.
The facts are that HHH does not count the conditional branch
instructions, when it is simulating itself. This makes HHH blind for
the specification in the input of the abort done by HHH and the
halting behaviour of the program.

HHH reaches its "return" instruction final halt state.

DDD correctly simulated by HHH cannot possibly reach
its own final halt state no matter what HHH does.

You are getting confused over what is being measured.
If we were measuring whether or not HHH halts then
you would be correct. *We are not measuring that*

You are confused. If HHH has a bug that does not allow it to reach the
final halt state of its simulation, then that is not a measure for the
halting behaviour specified in the input.
The bug in HHH has been spelled out to you many times, but it seems you
close your eyes and pretend that it does not exist.
The behaviour specified in the exact same input can be analysed in
different other ways. They all show that the analysis done by HHH is
incorrect. Therefore, the property(failure) of not being able to reach
the final halt state is a property of the simulator, not of the
simulated input.

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

On 6/29/25 9:29 AM, olcott wrote:

On 6/29/2025 5:34 AM, Fred. Zwarts wrote:

Op 28.jun.2025 om 15:08 schreef olcott:

On 6/28/2025 3:57 AM, Fred. Zwarts wrote:

Op 27.jun.2025 om 16:08 schreef olcott:

On 6/27/2025 2:59 AM, Fred. Zwarts wrote:

Op 27.jun.2025 om 06:26 schreef olcott:

On 6/26/2025 3:46 AM, Fred. Zwarts wrote:

Op 25.jun.2025 om 17:42 schreef olcott:

On 6/25/2025 2:38 AM, Mikko wrote:

On 2025-06-24 14:39:52 +0000, olcott said:

*ChatGPT and I agree that*
The directly executed DDD() is merely the first step of
otherwise infinitely recursive emulation that is terminated >>>>>>>>>>> at its second step.

No matter who agrees, the directly executed DDD is mote than >>>>>>>>>> merely the first step of otherwise infinitely recursive
emulation that is terminated at its second step. Not much
more but anyway. After the return of HHH(DDD) there is the >>>>>>>>>> return from DDD which is the last thing DDD does before its >>>>>>>>>> termination.

*HHH(DDD) the input to HHH specifies non-terminating behavior* >>>>>>>>> The fact that DDD() itself halts does not contradict that
because the directly executing DDD() cannot possibly be an
input to HHH in the Turing machine model of computation,
thus is outside of the domain of HHH.

Why repeating claims that have been proven incorrect.
The input to HHH is a pointer to code, that includes the code of >>>>>>>> HHH, including the code to abort and halt. Therefore, it
specifies a halting program.

*No, you are using an incorrect measure*
*I have addressed this too many times*

... with invalid measures.
The measure is not whether the simulator can do its job, the
measure is what the input specifies.

DDD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state *No matter what HHH does*
Therefore the input to HHH(DD) unequivocally
specifies non-halting behavior.

If the simulator cannot analyse this specification,

*It has been doing this correctly for several years*

Another invalid claim without evidence.
Bugs in your program have been pointed out to you for many years,
but you keep dreaming without taking notice of the facts.
The facts are that HHH does not count the conditional branch
instructions, when it is simulating itself. This makes HHH blind for
the specification in the input of the abort done by HHH and the
halting behaviour of the program.

HHH reaches its "return" instruction final halt state.

DDD correctly simulated by HHH cannot possibly reach
its own final halt state no matter what HHH does.

You are getting confused over what is being measured.
If we were measuring whether or not HHH halts then
you would be correct. *We are not measuring that*

You are confused. If HHH has a bug that does not allow it to reach the
final halt state of its simulation, then that is not a measure for the
halting behaviour specified in the input.

If HHH had a bug then someone could have pointed out the
exact bug on the last two years that its full source has
been available.  https://github.com/plolcott/x86utm

void DDD()
{
  HHH(DDD);
  return;
}

_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

HHH cannot possibly have a bug because the x86 source
code of DDD specifies that it cannot possibly reach its
"ret" instruction final halt state when emulated by
HHH according to the semantics of the x86 language.

Really.

Can't have a bug?

I guess giving the wrong answer isn't a bug in your view, because you
think lies are valid.

Note, the x86 source code of DDD says that for *ANY* HHH that exists and returns any value for a call to HHH(DDD), then DDD will halt.

Thus, ANY HHH that returns 0 from HHH(DDD) is wromg and has a "bug"

It seems your brain has a bug and thinks lies are ok, because the
definition of Halting isn't based on the partial emulation of some
family of deciders, but only on the behavior of the direct exectuition,
which will be copied by any CORRECT simulation/emulation of that program.

Of course, by the meaning of the words, the "C function" DDD doesn't
have behavior until converted into the PROGRAM DDD by pairing it with a definite version of HHH to call. Something that your buggy logic system
doesn't handle, because you seem to have caught a self-inflcted case of terminal stupidity.

The bug in HHH has been spelled out to you many times, but it seems
you close your eyes and pretend that it does not exist.
The behaviour specified in the exact same input can be analysed in
different other ways. They all show that the analysis done by HHH is
incorrect. Therefore, the property(failure) of not being able to reach
the final halt state is a property of the simulator, not of the
simulated input.

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

Op 29.jun.2025 om 15:29 schreef olcott:

On 6/29/2025 5:34 AM, Fred. Zwarts wrote:

Op 28.jun.2025 om 15:08 schreef olcott:

On 6/28/2025 3:57 AM, Fred. Zwarts wrote:

Op 27.jun.2025 om 16:08 schreef olcott:

On 6/27/2025 2:59 AM, Fred. Zwarts wrote:

Op 27.jun.2025 om 06:26 schreef olcott:

On 6/26/2025 3:46 AM, Fred. Zwarts wrote:

Op 25.jun.2025 om 17:42 schreef olcott:

On 6/25/2025 2:38 AM, Mikko wrote:

On 2025-06-24 14:39:52 +0000, olcott said:

*ChatGPT and I agree that*
The directly executed DDD() is merely the first step of
otherwise infinitely recursive emulation that is terminated >>>>>>>>>>> at its second step.

No matter who agrees, the directly executed DDD is mote than >>>>>>>>>> merely the first step of otherwise infinitely recursive
emulation that is terminated at its second step. Not much
more but anyway. After the return of HHH(DDD) there is the >>>>>>>>>> return from DDD which is the last thing DDD does before its >>>>>>>>>> termination.

*HHH(DDD) the input to HHH specifies non-terminating behavior* >>>>>>>>> The fact that DDD() itself halts does not contradict that
because the directly executing DDD() cannot possibly be an
input to HHH in the Turing machine model of computation,
thus is outside of the domain of HHH.

Why repeating claims that have been proven incorrect.
The input to HHH is a pointer to code, that includes the code of >>>>>>>> HHH, including the code to abort and halt. Therefore, it
specifies a halting program.

*No, you are using an incorrect measure*
*I have addressed this too many times*

... with invalid measures.
The measure is not whether the simulator can do its job, the
measure is what the input specifies.

DDD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state *No matter what HHH does*
Therefore the input to HHH(DD) unequivocally
specifies non-halting behavior.

If the simulator cannot analyse this specification,

*It has been doing this correctly for several years*

Another invalid claim without evidence.
Bugs in your program have been pointed out to you for many years,
but you keep dreaming without taking notice of the facts.
The facts are that HHH does not count the conditional branch
instructions, when it is simulating itself. This makes HHH blind for
the specification in the input of the abort done by HHH and the
halting behaviour of the program.

HHH reaches its "return" instruction final halt state.

DDD correctly simulated by HHH cannot possibly reach
its own final halt state no matter what HHH does.

You are getting confused over what is being measured.
If we were measuring whether or not HHH halts then
you would be correct. *We are not measuring that*

You are confused. If HHH has a bug that does not allow it to reach the
final halt state of its simulation, then that is not a measure for the
halting behaviour specified in the input.

If HHH had a bug then someone could have pointed out the
exact bug on the last two years that its full source has
been available.  https://github.com/plolcott/x86utm

Another counter-factual claim.
The bug has been presented to you many many times. The bug is that it
forgets to count the conditional branch instructions when simulating itself.

Your only rebuttal is repeating the same claims without any evidence.
That does not count as rebuttal.

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

Am Mon, 30 Jun 2025 11:33:40 -0500 schrieb olcott:

On 6/30/2025 2:38 AM, Fred. Zwarts wrote:

Op 29.jun.2025 om 15:29 schreef olcott:

On 6/29/2025 5:34 AM, Fred. Zwarts wrote:

Op 28.jun.2025 om 15:08 schreef olcott:

HHH reaches its "return" instruction final halt state.

Cool, that makes DDD loop forever.

DDD correctly simulated by HHH cannot possibly reach its own final
halt state no matter what HHH does.
You are getting confused over what is being measured. If we were
measuring whether or not HHH halts then you would be correct. *We
are not measuring that*

You are confused. If HHH has a bug that does not allow it to reach
the final halt state of its simulation, then that is not a measure
for the halting behaviour specified in the input.

If HHH had a bug then someone could have pointed out the exact bug on
the last two years that its full source has been available. 
https://github.com/plolcott/x86utm

Another counter-factual claim.
The bug has been presented to you many many times. The bug is that it
forgets to count the conditional branch instructions when simulating
itself.

The conditional branch instructions in HHH cannot possibly have any
effect whatsoever on whether or not the simulated DDD reaches its own "return" instruction final halt state.

But of course they do. Once as part of the outermost simulator, deter-
mining whether to abort, and once as part of DDD, determining whether
to return.

HHH simply simulates DDD with a pure simulator until it conclusively
proves that its outermost simulated DDD cannot possibly reach its own simulated "return" statement final halt state. When it aborts this DDD
all recursive emulations immediately stop.

Right, HHH is not a pure simulator. The simulations would have halted
if *only* the outermost HHH was pure and did not abort. *That* is what
what Sipser's twisted-by-you words meant, not simulating a different
DDD that calls a pure simulator. The code of DDD, including HHH, is
fixed and "describes" a partial simulator; you can't in a program
magically refer to "itself", you have to arrange for the explicit
mention to fall together with its name (except in Lisp maybe).

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

Am Mon, 30 Jun 2025 16:50:11 -0500 schrieb olcott:

On 6/30/2025 3:40 PM, joes wrote:

Am Mon, 30 Jun 2025 11:33:40 -0500 schrieb olcott:

The conditional branch instructions in HHH cannot possibly have any
effect whatsoever on whether or not the simulated DDD reaches its own
"return" instruction final halt state.

But of course they do. Once as part of the outermost simulator, deter-
mining whether to abort, and once as part of DDD, determining whether
to return.

HHH simply simulates DDD with a pure simulator until it conclusively
proves that its outermost simulated DDD cannot possibly reach its own
simulated "return" statement final halt state. When it aborts this DDD
all recursive emulations immediately stop.

Right, HHH is not a pure simulator.
The simulations would have halted if *only* the outermost HHH was pure
and did not abort.

Since you know that is impossible because every instance of HHH has the
exact same machine code at the same machine address why bring it up?

Read below.

*That* is what
what Sipser's twisted-by-you words meant, not simulating a different
DDD that calls a pure simulator. The code of DDD, including HHH, is
fixed and "describes" a partial simulator; you can't in a program
magically refer to "itself", you have to arrange for the explicit
mention to fall together with its name (except in Lisp maybe).

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

Op 30.jun.2025 om 23:50 schreef olcott:

On 6/30/2025 3:40 PM, joes wrote:

Am Mon, 30 Jun 2025 11:33:40 -0500 schrieb olcott:

On 6/30/2025 2:38 AM, Fred. Zwarts wrote:

Op 29.jun.2025 om 15:29 schreef olcott:

On 6/29/2025 5:34 AM, Fred. Zwarts wrote:

Op 28.jun.2025 om 15:08 schreef olcott:

HHH reaches its "return" instruction final halt state.

Cool, that makes DDD loop forever.

DDD correctly simulated by HHH cannot possibly reach its own final >>>>>>> halt state no matter what HHH does.
You are getting confused over what is being measured. If we were >>>>>>> measuring whether or not HHH halts then you would be correct. *We >>>>>>> are not measuring that*

You are confused. If HHH has a bug that does not allow it to reach >>>>>> the final halt state of its simulation, then that is not a measure >>>>>> for the halting behaviour specified in the input.

If HHH had a bug then someone could have pointed out the exact bug on >>>>> the last two years that its full source has been available.
https://github.com/plolcott/x86utm

Another counter-factual claim.
The bug has been presented to you many many times. The bug is that it
forgets to count the conditional branch instructions when simulating
itself.

The conditional branch instructions in HHH cannot possibly have any
effect whatsoever on whether or not the simulated DDD reaches its own
"return" instruction final halt state.

But of course they do. Once as part of the outermost simulator, deter-
mining whether to abort, and once as part of DDD, determining whether
to return.

HHH simply simulates DDD with a pure simulator until it conclusively
proves that its outermost simulated DDD cannot possibly reach its own
simulated "return" statement final halt state. When it aborts this DDD
all recursive emulations immediately stop.

Right, HHH is not a pure simulator.

The simulations would have halted
if *only* the outermost HHH was pure and did not abort.

Since you know that is impossible because
every instance of HHH has the exact same
machine code at the same machine address
why bring it up?

 *That* is what
what Sipser's twisted-by-you words meant, not simulating a different
DDD that calls a pure simulator. The code of DDD, including HHH, is
fixed and "describes" a partial simulator; you can't in a program
magically refer to "itself", you have to arrange for the explicit
mention to fall together with its name (except in Lisp maybe).

The input to HHH(DDD) never stops running unless aborted
is saying the same thing as DDD correctly simulated by HHH:

HHH(DDD) simulates DDD that calls HHH(DDD)
simulates DDD that calls HHH(DDD)
simulates DDD that calls HHH(DDD)
simulates DDD that calls HHH(DDD)
simulates DDD that calls HHH(DDD)
simulates DDD that calls HHH(DDD)

Cannot possibly reach its own simulated
"return" statement final halt state.

Why repeating this failure of HHH? The simulated HHH, as you yourself
admitted a few lines above, has the same code as the simulating HHH. If
the simulating HHH is programmed to abort after a few cycles, the input
for the simulating HHH specifies the same aborting code. Indeed, HHH has
a bug so that it cannot reach that part of the specification, but that
does not change the specification, it only makes HHH blind for that part
of the specification.
Another effect of you strange construction is, that the input changes as
soon as you change HHH. This makes you blind for the fact that each
aborting HHH aborts just one cycle too soon, reporting an incorrect
result, where the not-aborting HHH never returns to report.
You would help yourself with a construction where the simulating HHH and
the simulated HHH would not reside in the same memory, but where the
simulated HHH is a copy of the simulating HHH. Then it becomes more
evident what exactly is the behaviour of the program specified in the
input and what is the behaviour of the simulator.

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

Am Tue, 01 Jul 2025 06:38:50 -0500 schrieb olcott:

On 7/1/2025 3:56 AM, joes wrote:

Am Mon, 30 Jun 2025 16:50:11 -0500 schrieb olcott:

On 6/30/2025 3:40 PM, joes wrote:

Am Mon, 30 Jun 2025 11:33:40 -0500 schrieb olcott:

The conditional branch instructions in HHH cannot possibly have any
effect whatsoever on whether or not the simulated DDD reaches its
own "return" instruction final halt state.

But of course they do. Once as part of the outermost simulator,
deter mining whether to abort, and once as part of DDD, determining
whether to return.

I'll take this as accepted.

HHH simply simulates DDD with a pure simulator until it conclusively >>>>> proves that its outermost simulated DDD cannot possibly reach its
own simulated "return" statement final halt state. When it aborts
this DDD all recursive emulations immediately stop.

Right, HHH is not a pure simulator.
The simulations would have halted if *only* the outermost HHH was
pure and did not abort.

Since you know that is impossible because every instance of HHH has
the exact same machine code at the same machine address why bring it
up?

Read below.

*There is not good reason to begin reasoning with a lie*

What lie?
Simulating DDD with a pure simulator halts, which is the hypothetical
of your pet misquote, not a pure simulator simulating DDD'(){HHH'(DDD');}.
You think that termination analysers should change all calls to more
TAs in the input to pure simulators.

*That* is what
what Sipser's twisted-by-you words meant, not simulating a different
DDD that calls a pure simulator. The code of DDD, including HHH, is
fixed and "describes" a partial simulator; you can't in a program
magically refer to "itself", you have to arrange for the explicit
mention to fall together with its name (except in Lisp maybe).

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