Am Wed, 30 Jul 2025 09:12:00 -0500 schrieb olcott:

On 7/30/2025 4:09 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 07:00 schreef olcott:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:

It is a lack of technical ability on your part which is unable to
judge whether such a correct simulation is possible.  Everybody else
sees that it is not, so further questions about it are non-sensical.

I have no idea why are are saying the something that is trivial is
impossible.

You keep saying HHH can't simulate DDD to completion.

When HHH emulates: "push ebp" then HHH has correctly emulated the
first instruction of DDD correctly.

Simulating a few instructions does not make the whole simulation
correct.

Simulating N instructions correctly does mean that these N instructions
were simulated correctly.

Simulating N instructions means that not all instructions were simulated.

In contrast, the failure to simulate a single instruction correctly,
makes the whole simulation incorrect.
In this case it is the failure to simulate the call instruction.

My code conclusively proves that HHH does simulate itself simulating
DDD.

No, HHH aborts.

The simulation aborts at this point, where the semantics of the x86
language requires the execution of the next instruction.

My code conclusively proves that HHH does simulate itself simulating DDD until any sufficiently competent person can correctly determine a
repeating pattern that cannot possibly reach its own "return" statement
final halt state even with an infinite simulation.

That is incorrect. For every HHH-like that aborts after some fixed
finite number of recursions we can indeed construct a DDD-like*
such that this particular HHH_n aborts DDD_n before that returns.
But HHH_n+1 CAN simulate DDD_n to termination without aborting!

If we modified HHH to abort one repetition later, you are incorrectly
also modifying the input DDD to call this new HHH'. That is not the
same program. There is no magic 'call my simulator' instruction. The
code of DDD is fixed and includes one particular version of HHH.

This premature abort, based on the incorrect assumption that a
finite
recursion specifies non-halting, makes the whole simulation incorrect
and, what is worse, the conclusion of non-halting behaviour fails.

HHH has no idea that DDD is calling itself.
HHH just sees that DDD is calling the same function with the same
parameter twice in sequence, just like Infinite_Recursion().

Alas, the simulated HHH would return soon, if it weren't aborted.

Further irrelevant claims without evidence ignored.

--
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 7/30/25 11:10 AM, olcott wrote:

On 7/30/2025 9:44 AM, joes wrote:

Am Wed, 30 Jul 2025 09:12:00 -0500 schrieb olcott:

On 7/30/2025 4:09 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 07:00 schreef olcott:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:

It is a lack of technical ability on your part which is unable to
judge whether such a correct simulation is possible.  Everybody else >>>>>> sees that it is not, so further questions about it are non-sensical. >>>>>>

I have no idea why are are saying the something that is trivial is
impossible.

You keep saying HHH can't simulate DDD to completion.

*Because completion does not exist*

But it DOES, as shown by HHH1.

The problem is the DDD given to HHH has as its HHH the HHH that aborts
and returns 0, because that IS what you say HHH does

All you are doing is showing that you think it is ok to lie about what
things are.

Just like completion does not exist for these two:

void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}

void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}

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

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

On 7/30/2025 6:26 PM, Richard Damon wrote:

Neither was all of the instructions of the above simulated correctly.
When N instructions are simulated correctly the repeating pattern
emerges.

So?

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

Nope, the first HHH simulated will abort the simulation before we get
here.

Not at all. My encoded HHH aborts as soon as it sees the pattern repeat
once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern
repeat ten times.

Yes, it could. In which case it would only see 3 repetitions before
the simulated HHH aborts (incorrectly, because it still only waits
for 2 repetitions).

--
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 7/30/25 7:49 PM, olcott wrote:

On 7/30/2025 6:27 PM, Richard Damon wrote:

On 7/30/25 11:10 AM, olcott wrote:

On 7/30/2025 9:44 AM, joes wrote:

Am Wed, 30 Jul 2025 09:12:00 -0500 schrieb olcott:

On 7/30/2025 4:09 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 07:00 schreef olcott:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:

It is a lack of technical ability on your part which is unable to >>>>>>>> judge whether such a correct simulation is possible.  Everybody >>>>>>>> else
sees that it is not, so further questions about it are non-
sensical.

I have no idea why are are saying the something that is trivial is >>>>>>> impossible.

You keep saying HHH can't simulate DDD to completion.

*Because completion does not exist*

But it DOES, as shown by HHH1.

HHH  Does simulate itself simulating DDD
HHH2 Does NOT simulate itself simulating DDD
and Richard is too fucking dishonest to acknowledge this.

But "itself" doesn't matter.

They both simulate the exact same code, that of HHH(DDD) that then
simulated DDD, and thus SHOULD get the same result, but HHH gives up too
soon.

If you think there is a difference in the simulation, what x86
instruction depend on what is simulating it?

You lack of answer just proves you KNOW you are lying but can't face the
truth, because you have brainwashed yourself into beleiving you lies,
putting you into the state of being a pathological liar.

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

Am Thu, 31 Jul 2025 00:40:17 -0500 schrieb olcott:

On 7/31/2025 12:36 AM, joes wrote:

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

On 7/30/2025 6:26 PM, Richard Damon wrote:

Neither was all of the instructions of the above simulated
correctly.
When N instructions are simulated correctly the repeating pattern
emerges.

So?

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

Nope, the first HHH simulated will abort the simulation before we get
here.

Not at all. My encoded HHH aborts as soon as it sees the pattern
repeat once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern
repeat ten times.

Yes, it could. In which case it would only see 3 repetitions before the
simulated HHH aborts (incorrectly, because it still only waits for 2
repetitions).

They all use the exact same machine code otherwise that is cheating.

No, you can't change the input depending on the simulator.

--
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 Thu, 31 Jul 2025 00:55:18 -0500 schrieb olcott:

On 7/31/2025 12:46 AM, joes wrote:

Am Thu, 31 Jul 2025 00:40:17 -0500 schrieb olcott:

On 7/31/2025 12:36 AM, joes wrote:

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

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

Nope, the first HHH simulated will abort the simulation before we
get here.

Not at all. My encoded HHH aborts as soon as it sees the pattern
repeat once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern
repeat ten times.

Yes, it could. In which case it would only see 3 repetitions before
the simulated HHH aborts (incorrectly, because it still only waits
for 2 repetitions).

They all use the exact same machine code otherwise that is cheating.

No, you can't change the input depending on the simulator.

How can the exact same unchanged sequence of machine code bytes be
different than it is?

Excellent question! DDD is not a template that calls its own simulator
or whatever HHH refers to. It is a concrete program that calls your
particular implementation which aborts after the second repetition.
If you then try to modify *the simulator* (not the name "HHH") you
must keep DDD fixed, including its version of HHH. Otherwise you are
not simulating the same program.

--
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 7/31/25 1:40 AM, olcott wrote:

On 7/31/2025 12:36 AM, joes wrote:

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

On 7/30/2025 6:26 PM, Richard Damon wrote:

Neither was all of the instructions of the above simulated correctly. >>>>> When N instructions are simulated correctly the repeating pattern
emerges.

So?

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

Nope, the first HHH simulated will abort the simulation before we get
here.

Not at all. My encoded HHH aborts as soon as it sees the pattern repeat
once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern
repeat ten times.

Yes, it could. In which case it would only see 3 repetitions before
the simulated HHH aborts (incorrectly, because it still only waits
for 2 repetitions).

They all use the exact same machine code
otherwise that is cheating.

No, DDD only needs to have a functional copy of HHH.

This is one of your problems of not keeping the seperate programs in
seperate memory spaces.

And since DDD contains the code of the specific HHH that it was defined
to call, and changing that changes "the input", it seems that all you
ideas of altering HHH to be something other that that specific HHH are
ruled out, because you can't put two different sets of code into the
same memory space.

Again, why the combined memory space is wrong.

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

On 7/31/25 1:55 AM, olcott wrote:

On 7/31/2025 12:46 AM, joes wrote:

Am Thu, 31 Jul 2025 00:40:17 -0500 schrieb olcott:

On 7/31/2025 12:36 AM, joes wrote:

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

On 7/30/2025 6:26 PM, Richard Damon wrote:

Neither was all of the instructions of the above simulated
correctly.
When N instructions are simulated correctly the repeating pattern >>>>>>> emerges.

So?

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

Nope, the first HHH simulated will abort the simulation before we get >>>>>> here.

Not at all. My encoded HHH aborts as soon as it sees the pattern
repeat once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern
repeat ten times.

Yes, it could. In which case it would only see 3 repetitions before the >>>> simulated HHH aborts (incorrectly, because it still only waits for 2
repetitions).

They all use the exact same machine code otherwise that is cheating.

No, you can't change the input depending on the simulator.

How can the exact same unchanged sequence of machine code bytes
be different than it is?

Exactly.

How can the bytes of HHH called by DDD get stuck in infinite recursion,
when the exact same code of HHH doing the outer emulation doesn't?

Answer, it can't, and thus HHH and YOU were just wrong in determining
that it would, because you keep on trying to use wrong definitions.

You are just wrong about what DDD does, because you ignore your
definition of HHH and lie to yourself about what it is, because you
don't actually properly define it to yourself.

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

On 7/31/25 11:59 AM, olcott wrote:

On 7/31/2025 6:02 AM, Richard Damon wrote:

On 7/31/25 1:40 AM, olcott wrote:

On 7/31/2025 12:36 AM, joes wrote:

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

On 7/30/2025 6:26 PM, Richard Damon wrote:

Neither was all of the instructions of the above simulated
correctly.
When N instructions are simulated correctly the repeating pattern >>>>>>> emerges.

So?

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

Nope, the first HHH simulated will abort the simulation before we get >>>>>> here.

Not at all. My encoded HHH aborts as soon as it sees the pattern
repeat
once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern
repeat ten times.

Yes, it could. In which case it would only see 3 repetitions before
the simulated HHH aborts (incorrectly, because it still only waits
for 2 repetitions).

They all use the exact same machine code
otherwise that is cheating.

No, DDD only needs to have a functional copy of HHH.

The actual fact is that they all have the exact
same machine code at the same machine address.

WHich means that the HHH that DDD calls will return 0 to it just as the
HHH that main calls.

Thus HHH was INCORRECT in its simulation of the input.

Note, you talking of some other HHH can't exist, as then you don't have
that same machine code at the same machine address.

That other HHH needs to be like HHH1, and that shows that HHH SHOULD
HAVE simulate THIS input and not aborted, but of course, since its code
said to abort, it had to do that.

Sorry, youa are just proving that you are just a liar.

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

On 7/31/25 12:02 PM, olcott wrote:

On 7/31/2025 6:05 AM, Richard Damon wrote:

On 7/31/25 1:55 AM, olcott wrote:

On 7/31/2025 12:46 AM, joes wrote:

Am Thu, 31 Jul 2025 00:40:17 -0500 schrieb olcott:

On 7/31/2025 12:36 AM, joes wrote:

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

On 7/30/2025 6:26 PM, Richard Damon wrote:

Neither was all of the instructions of the above simulated
correctly.
When N instructions are simulated correctly the repeating pattern >>>>>>>>> emerges.

So?

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

Nope, the first HHH simulated will abort the simulation before >>>>>>>> we get
here.

Not at all. My encoded HHH aborts as soon as it sees the pattern >>>>>>> repeat once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern >>>>>>> repeat ten times.

Yes, it could. In which case it would only see 3 repetitions
before the
simulated HHH aborts (incorrectly, because it still only waits for 2 >>>>>> repetitions).

They all use the exact same machine code otherwise that is cheating.

No, you can't change the input depending on the simulator.

How can the exact same unchanged sequence of machine code bytes
be different than it is?

Exactly.

How can the bytes of HHH called by DDD get stuck in infinite
recursion, when the exact same code of HHH doing the outer emulation
doesn't?

Your severe brain damage / dementia has you
keep forgetting this from one post to the next.

HHH(DDD) has DDD call HHH(DDD) in recursive simulation.
HHH1(DDD) DOES NOT HAVE DDD call HHH1(DDD) in recursive simulation.

But the simulation doesn't matter at what point it become "recursive" as
it is always the same program, and thus the simulation is identical.

You don't seem to understand that fundamental fact, there is no point in
the simulation of DDD, where it makes a difference in the actual
behavior of that input, or its correct simulation, whether it is HHH
simulating "itself" or HHH1 simulating something that isn't itself.

That you claim is does, but can't prove that, just shows you are just a
stupid liar that don't no the basic principles of Programming.

That is what make you a pathological liar.

Try to show the first instruciton, properly simulated by the rules of
the x86 language, where it makes a difference of who is simulating it.

Your LYING DODGE of trying to comptess the call to HHH to be other than
the x86 emulation of it just shows your stupidity, because you have HHH
lie to itself what HHH does, because that is all you know how to do it.

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

On 7/31/25 8:05 PM, olcott wrote:

On 7/31/2025 6:45 PM, Richard Damon wrote:

On 7/31/25 12:02 PM, olcott wrote:

On 7/31/2025 6:05 AM, Richard Damon wrote:

On 7/31/25 1:55 AM, olcott wrote:

On 7/31/2025 12:46 AM, joes wrote:

Am Thu, 31 Jul 2025 00:40:17 -0500 schrieb olcott:

On 7/31/2025 12:36 AM, joes wrote:

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

On 7/30/2025 6:26 PM, Richard Damon wrote:

Neither was all of the instructions of the above simulated >>>>>>>>>>> correctly.
When N instructions are simulated correctly the repeating >>>>>>>>>>> pattern
emerges.

So?

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

Nope, the first HHH simulated will abort the simulation before >>>>>>>>>> we get
here.

Not at all. My encoded HHH aborts as soon as it sees the pattern >>>>>>>>> repeat once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern >>>>>>>>> repeat ten times.

Yes, it could. In which case it would only see 3 repetitions
before the
simulated HHH aborts (incorrectly, because it still only waits >>>>>>>> for 2
repetitions).

They all use the exact same machine code otherwise that is cheating. >>>>>> No, you can't change the input depending on the simulator.

How can the exact same unchanged sequence of machine code bytes
be different than it is?

Exactly.

How can the bytes of HHH called by DDD get stuck in infinite
recursion, when the exact same code of HHH doing the outer emulation
doesn't?

Your severe brain damage / dementia has you
keep forgetting this from one post to the next.

HHH(DDD) has DDD call HHH(DDD) in recursive simulation.
HHH1(DDD) DOES NOT HAVE DDD call HHH1(DDD) in recursive simulation.

But the simulation doesn't matter at what point it become "recursive"
as it is always the same program, and thus the simulation is identical.

In other words you cannot begin to understand the notion
of recursive simulation.

Sure I do.

THe problem is you don't understand that what you have created is a
finite recursion of partial simulations.

Alan Mackenzie might actually believe that this impossible
for HHH to emulate an instance of itself emulating DDD on
a basis such as he never heard of multi-tasking. This may
be the case with several other people here.

Have you ever heard of multi-tasking?

Because HHH CAN'T correctly (which means completely) simulate such an input.

Multi-tasking doesn't help with this.

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

On 7/31/25 8:08 PM, olcott wrote:

On 7/31/2025 6:48 PM, Richard Damon wrote:

On 7/31/25 11:59 AM, olcott wrote:

On 7/31/2025 6:02 AM, Richard Damon wrote:

On 7/31/25 1:40 AM, olcott wrote:

On 7/31/2025 12:36 AM, joes wrote:

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

On 7/30/2025 6:26 PM, Richard Damon wrote:

Neither was all of the instructions of the above simulated
correctly.
When N instructions are simulated correctly the repeating pattern >>>>>>>>> emerges.

So?

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

Nope, the first HHH simulated will abort the simulation before >>>>>>>> we get
here.

Not at all. My encoded HHH aborts as soon as it sees the pattern >>>>>>> repeat
once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern >>>>>>> repeat ten times.

Yes, it could. In which case it would only see 3 repetitions before >>>>>> the simulated HHH aborts (incorrectly, because it still only waits >>>>>> for 2 repetitions).

They all use the exact same machine code
otherwise that is cheating.

No, DDD only needs to have a functional copy of HHH.

The actual fact is that they all have the exact
same machine code at the same machine address.

WHich means that the HHH that DDD calls will return 0 to it just as
the HHH that main calls.

It may seem that way if you utterly fail to understand
the notion of recursive emulation. Your failure to
understand is not at all my mistake.

No, it seems you don't understand that it is finite recursion of partial emulations.

Part of the problem is you don't understand what CORRECT
simulation/emulation means, becaus you have just lied to your ignorant self.

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

On 7/31/25 8:08 PM, olcott wrote:

On 7/31/2025 6:48 PM, Richard Damon wrote:

On 7/31/25 11:59 AM, olcott wrote:

On 7/31/2025 6:02 AM, Richard Damon wrote:

On 7/31/25 1:40 AM, olcott wrote:

On 7/31/2025 12:36 AM, joes wrote:

Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:

On 7/30/2025 7:07 PM, Richard Damon wrote:

On 7/30/25 7:46 PM, olcott wrote:

On 7/30/2025 6:26 PM, Richard Damon wrote:

Neither was all of the instructions of the above simulated
correctly.
When N instructions are simulated correctly the repeating pattern >>>>>>>>> emerges.

So?

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

Nope, the first HHH simulated will abort the simulation before >>>>>>>> we get
here.

Not at all. My encoded HHH aborts as soon as it sees the pattern >>>>>>> repeat
once.

Yes, exactly. I snipped it above to that.

It could have been encoded to wait until it sees this same pattern >>>>>>> repeat ten times.

Yes, it could. In which case it would only see 3 repetitions before >>>>>> the simulated HHH aborts (incorrectly, because it still only waits >>>>>> for 2 repetitions).

They all use the exact same machine code
otherwise that is cheating.

No, DDD only needs to have a functional copy of HHH.

The actual fact is that they all have the exact
same machine code at the same machine address.

WHich means that the HHH that DDD calls will return 0 to it just as
the HHH that main calls.

It may seem that way if you utterly fail to understand
the notion of recursive emulation. Your failure to
understand is not at all my mistake.

No, you fail to understand that what you have is FINITE recursion of
Partial SImulation, which halts.

Part of your problem is you have lied to you ignorant self what correct simulation means, and what halting/non-halting means.

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

Am Sat, 02 Aug 2025 08:35:10 -0500 schrieb olcott:

On 8/2/2025 4:11 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 08:02 schreef olcott:

On 8/2/2025 12:55 AM, joes wrote:

Am Fri, 01 Aug 2025 12:16:01 -0500 schrieb olcott:

On 8/1/2025 11:30 AM, joes wrote:

Am Fri, 01 Aug 2025 11:08:56 -0500 schrieb olcott:

On 8/1/2025 10:35 AM, joes wrote:

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

On 8/1/2025 10:05 AM, joes wrote:

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

On 8/1/2025 1:53 AM, joes wrote:

And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>> state.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts its >>>>>>>>>>> input.

"HHH simulating DDD doesn't halt unless it aborts." Which it
does.

Infinite_Loop correctly simulated by HHH stops running very
quickly.

Unlike DDD, Infinite_Loop *would* repeat the pattern.

Of the infinite set of HHH that stops simulating and aborts after N
recursive simulations one of them is the above HHH.
What no one has acknowledged in three years is that when N
instructions of DDD are correctly emulated by some HHH that none of
these DDD instances ever reaches its own "return" statement final
halt state.

Because they are all simulating different programs.

That is not relevant.

It is most certainly relevant what program is being simulated.

This failure is seen by all these programs, showing that a simulation
with a premature abort is not the right way to analyse the behaviour of
a program.

How many recursive simulations before DDD halts on its own?

Hey, I already answered this: three levels.
Of course HHH only simulates two and never gets there. But HHH',
simulating DDD (which still calls HHH, not HHH') three levels deep,
would.

--
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/2/25 2:50 PM, olcott wrote:

On 8/2/2025 1:39 PM, joes wrote:

Am Sat, 02 Aug 2025 08:35:10 -0500 schrieb olcott:

On 8/2/2025 4:11 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 08:02 schreef olcott:

On 8/2/2025 12:55 AM, joes wrote:

Am Fri, 01 Aug 2025 12:16:01 -0500 schrieb olcott:

On 8/1/2025 11:30 AM, joes wrote:

Am Fri, 01 Aug 2025 11:08:56 -0500 schrieb olcott:

On 8/1/2025 10:35 AM, joes wrote:

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

On 8/1/2025 10:05 AM, joes wrote:

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

On 8/1/2025 1:53 AM, joes wrote:

And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>> state.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts its >>>>>>>>>>>>> input.

"HHH simulating DDD doesn't halt unless it aborts." Which it >>>>>>>>>> does.

Infinite_Loop correctly simulated by HHH stops running very
quickly.

Unlike DDD, Infinite_Loop *would* repeat the pattern.

Of the infinite set of HHH that stops simulating and aborts after N >>>>>>> recursive simulations one of them is the above HHH.
What no one has acknowledged in three years is that when N
instructions of DDD are correctly emulated by some HHH that none of >>>>>>> these DDD instances ever reaches its own "return" statement final >>>>>>> halt state.

Because they are all simulating different programs.

That is not relevant.

It is most certainly relevant what program is being simulated.

This failure is seen by all these programs, showing that a simulation
with a premature abort is not the right way to analyse the behaviour of >>>> a program.

How many recursive simulations before DDD halts on its own?

Hey, I already answered this: three levels.
Of course HHH only simulates two and never gets there. But HHH',
simulating DDD (which still calls HHH, not HHH') three levels deep,
would.

How many recursive simulations before the simulated
DDD halts on its own?

One more than HHH simulates.

So, to get a correct simulaton from HHH, you need to find an N that
satisfies N >= N+1

Unfortunately, no such N exists, until you get transfinite.

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