From Newsgroup: comp.ai.philosophy

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

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

_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e
[000021a6] e843f4ffff     call 000015ee
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]

cant' be the full input as not simuatable.

We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.

The Call HHH instruction below.

Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.

Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.

  machine   stack     stack     machine        assembly >>   address   address   data      code           language >>   ========  ========  ========  ========== =============
[000021be][00103872][00000000] 55         push ebp
[000021bf][00103872][00000000] 8bec       mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
[000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916

Not a correct simulation of the call HHH instruction.

Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e
[0000219e][0011390e][00113912] 55         push ebp
[0000219f][0011390e][00113912] 8bec       mov ebp,esp
[000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55         push ebp
[0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
[000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH

The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.

It also shows the repeating pattern that DDD correctly
emulated by DDD derives.

Without even having an implemented HHH we can still
see that DDD emulated by an emulated HHH would produce
this same same repeating pattern.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 7/30/25 8:42 PM, olcott wrote:

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

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

_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e
[000021a6] e843f4ffff     call 000015ee
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]

cant' be the full input as not simuatable.

We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.

The Call HHH instruction below.

Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.

Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.

  machine   stack     stack     machine        assembly >>>   address   address   data      code           language
  ========  ========  ========  ========== =============
[000021be][00103872][00000000] 55         push ebp
[000021bf][00103872][00000000] 8bec       mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
[000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916

Not a correct simulation of the call HHH instruction.

Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e >>> [0000219e][0011390e][00113912] 55         push ebp
[0000219f][0011390e][00113912] 8bec       mov ebp,esp
[000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55         push ebp
[0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
[000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH

The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.

No, because you don't show the simulation of the code of HHH.

I guess you don't know what that means.

It also shows the repeating pattern that DDD correctly
emulated by DDD derives.

But that isn't what actually happens. the second copy doesn't actually
happen in the actual simulation of the input.

Without even having an implemented HHH we can still
see that DDD emulated by an emulated HHH would produce
this same same repeating pattern.

But if HHH isn't implements, you can't HAVE DDD as a valid input.

All you are doing is proving you are just lying about what you are doing.

You are just proving that your whold argument is based on category
errors and lies.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 7/30/2025 9:16 PM, Richard Damon wrote:

On 7/30/25 8:42 PM, olcott wrote:

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

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

_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e
[000021a6] e843f4ffff     call 000015ee
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]

cant' be the full input as not simuatable.

We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.

The Call HHH instruction below.

Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.

Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.

  machine   stack     stack     machine        assembly >>>>   address   address   data      code           language
  ========  ========  ========  ========== =============
[000021be][00103872][00000000] 55         push ebp
[000021bf][00103872][00000000] 8bec       mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
[000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916

Not a correct simulation of the call HHH instruction.

Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e >>>> [0000219e][0011390e][00113912] 55         push ebp
[0000219f][0011390e][00113912] 8bec       mov ebp,esp
[000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55         push ebp
[0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
[000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH

The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.

No, because you don't show the simulation of the code of HHH.

Mixing the above 8 instructions in with another 176
pages of instructions does not help understanding
things.

https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

We can know that HHH did correctly emulate itself
emulating DDD because this emulated HHH does derive
the correct first four instructions of DDD.

I guess you don't know what that means.

It also shows the repeating pattern that DDD correctly
emulated by DDD derives.

But that isn't what actually happens. the second copy doesn't actually happen in the actual simulation of the input.

Counter-factual and this proves that it is counter-factual https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Without even having an implemented HHH we can still
see that DDD emulated by an emulated HHH would produce
this same same repeating pattern.

But if HHH isn't implements, you can't HAVE DDD as a valid input.

HHH is implemented yet too difficult for you to
understand so we verify that DDD does emulate
itself emulating DDD in that its emulated DDD
does emulate the first four instructions of DDD
as shown above.

All you are doing is proving you are just lying about what you are doing.

That you call me a liar could get you condemned to actual Hell.
Revelations 21:8
...all liars, their lot shall be in the lake that burns
with fire and sulphur, which is the second death.”

You are just proving that your whold argument is based on category
errors and lies.

That you keep changing the words that I say to make your
rebuttal easier is the strawman deception can could get you
condemned to actual Hell.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

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

On 7/30/2025 9:16 PM, Richard Damon wrote:

On 7/30/25 8:42 PM, olcott wrote:

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

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

_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e
[000021a6] e843f4ffff     call 000015ee
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]

cant' be the full input as not simuatable.

We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.

The Call HHH instruction below.

Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.

Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.

  machine   stack     stack     machine        assembly
  address   address   data      code           language
  ========  ========  ========  ========== =============
[000021be][00103872][00000000] 55         push ebp
[000021bf][00103872][00000000] 8bec       mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD
[000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916

Not a correct simulation of the call HHH instruction.

Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e >>>>> [0000219e][0011390e][00113912] 55         push ebp
[0000219f][0011390e][00113912] 8bec       mov ebp,esp
[000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55         push ebp
[0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
[000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD
[000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH

The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.

No, because you don't show the simulation of the code of HHH.

Mixing the above 8 instructions in with another 176
pages of instructions does not help understanding
things.

And FAILING to do it is just a lie.

https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Which, as has been pointed out, NOT the trace generated by HHH
simulating DDD, as it begins at main, which HHH NEVER simulates.

Thus, you are showing you don't know what you are talking about.

Perhaps if you removed that extraneous level of simulation into one
trace, you would get likely a 3-10 page trace of what HHH actually sees
in its simulation, which could be compared to the first pages of that
176 page simulation of main (which looks just like DDD except for the
address it is at) with HHHs simulation, and see that they EXACTLY match,
and since the 176 pages reach a final state, the 3-10 pages can't have a non-halting pattern in them.

We can know that HHH did correctly emulate itself
emulating DDD because this emulated HHH does derive
the correct first four instructions of DDD.

Nope, that ignores critical details of HHHs behavior, thus showing that
you are just trying to hide your lies.

Note, the extra layer that you show is just a Red Herring,

I guess you don't know what that means.

It also shows the repeating pattern that DDD correctly
emulated by DDD derives.

But that isn't what actually happens. the second copy doesn't actually
happen in the actual simulation of the input.

Counter-factual and this proves that it is counter-factual https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Nope, as explained above, you just lie about what that is.

Note, Your "trace" results are merged from every level of the
simulation, and thus isn't a single correct trace of anybody, but the
correct trace CAN be worked out with a bit of work.

That shows that the code of Main/DDD calling HHH(DDD) will eventually
return to a final state.

The SImulaiton that HHH does aborts part way through that simulation,
and thus fails to be the correct simulaition, as that is required to be complete.

Thus, all your claims are just shown to be a lie.

Until you actually point out a specific errot in those statements, you
are just proving that you are nothing but a pathological liar that
doesn't actually care about be correct.

Without even having an implemented HHH we can still
see that DDD emulated by an emulated HHH would produce
this same same repeating pattern.

But if HHH isn't implements, you can't HAVE DDD as a valid input.

HHH is implemented yet too difficult for you to
understand so we verify that DDD does emulate
itself emulating DDD in that its emulated DDD
does emulate the first four instructions of DDD
as shown above.

You can't HAVE DDD until you implement HHH.

Sorry, you are just proving you don't understand the basics of what you
are talking about, and everything you say is based on LIES.

All you are doing is proving you are just lying about what you are doing.

That you call me a liar could get you condemned to actual Hell.
Revelations 21:8
...all liars, their lot shall be in the lake that burns
with fire and sulphur, which is the second death.”

Since my statements are NOT lies, I don't need to worry about that. I
can reference the actual definitios that support what I say.

Since you CAN'T, because you chose to not know the meanings, but are
just guessing, you have chose the way of the ignorant liar, who is
doomed to that fate.

Are you really that sure of the stuff you just made up to bet on that?

You are just proving that your whold argument is based on category
errors and lies.

That you keep changing the words that I say to make your
rebuttal easier is the strawman deception can could get you
condemned to actual Hell.

No, I use the words you use in there actual meaning.

I point out that YOU have changed the definition of the problem, and
point out that BY THE DEFINITION you are wrong.

That you keep on insisting the problem means something it doesn't just
make you a liar.

That you can't understand those meanings just makes you stupid.

Your ignorance and inability to understand statements, doesn't make the
wrong, only your denial of them is wrong.

Sorry, it look like you have booked your ticket to that lake of fire.

You might have made advanced reservations years ago when you claimed to
be God, as that is also is one of the bigger qualifications for that trip.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

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

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

On 7/30/2025 9:16 PM, Richard Damon wrote:

On 7/30/25 8:42 PM, olcott wrote:

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

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

_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e
[000021a6] e843f4ffff     call 000015ee
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]

cant' be the full input as not simuatable.

We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.

The Call HHH instruction below.

Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.

Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.

  machine   stack     stack     machine        assembly
  address   address   data      code           language
  ========  ========  ========  ========== =============
[000021be][00103872][00000000] 55         push ebp
[000021bf][00103872][00000000] 8bec       mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD >>>>>> [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH >>>>>> New slave_stack at:103916

Not a correct simulation of the call HHH instruction.

Begin Local Halt Decider Simulation   Execution Trace Stored
at:11391e
[0000219e][0011390e][00113912] 55         push ebp
[0000219f][0011390e][00113912] 8bec       mov ebp,esp
[000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD >>>>>> [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH >>>>>> New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55         push ebp
[0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
[000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD >>>>>> [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH >>>>>>

The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.

No, because you don't show the simulation of the code of HHH.

Mixing the above 8 instructions in with another 176
pages of instructions does not help understanding
things.

And FAILING to do it is just a lie.

https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Which, as has been pointed out, NOT the trace generated by HHH
simulating DDD, as it begins at main, which HHH NEVER simulates.

HHH simulates DDD then simulates a different instance
of itself simulating a different instance of DDD which
calls another different instance of HHH(DDD)...
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 7/31/25 7:54 PM, olcott wrote:

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

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

On 7/30/2025 9:16 PM, Richard Damon wrote:

On 7/30/25 8:42 PM, olcott wrote:

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

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

_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e
[000021a6] e843f4ffff     call 000015ee
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]

cant' be the full input as not simuatable.

We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.

The Call HHH instruction below.

Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.

Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.

  machine   stack     stack     machine        assembly
  address   address   data      code           language
  ========  ========  ========  ========== =============
[000021be][00103872][00000000] 55         push ebp
[000021bf][00103872][00000000] 8bec       mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD >>>>>>> [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH >>>>>>> New slave_stack at:103916

Not a correct simulation of the call HHH instruction.

Begin Local Halt Decider Simulation   Execution Trace Stored
at:11391e
[0000219e][0011390e][00113912] 55         push ebp
[0000219f][0011390e][00113912] 8bec       mov ebp,esp
[000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD >>>>>>> [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH >>>>>>> New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55         push ebp
[0000219f][0015e336][0015e33a] 8bec       mov ebp,esp
[000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD >>>>>>> [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH >>>>>>>

The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.

No, because you don't show the simulation of the code of HHH.

Mixing the above 8 instructions in with another 176
pages of instructions does not help understanding
things.

And FAILING to do it is just a lie.

https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Which, as has been pointed out, NOT the trace generated by HHH
simulating DDD, as it begins at main, which HHH NEVER simulates.

HHH simulates DDD then simulates a different instance
of itself simulating a different instance of DDD which
calls another different instance of HHH(DDD)...

Nope. That isn't what you code, or your simulation of it shows.

I guess you forgot how you defined HHH.

Your HHH is defined to abort its simulation, at a specific point.

Anything else is just you LYING about HHH.

Looks like you are booking your trip to the lake.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

Op 30.jul.2025 om 16:52 schreef olcott:

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

Op 30.jul.2025 om 05:12 schreef olcott:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*

Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.

Indeed. But there are different reasons:
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,

*I challenge you to show a premature abort*

This has been presented tro you many times, but you close your eyes for
it and pretend that it does not exist.>

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

We have told you that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all function
called by DDD, directly or indirectly, including the HHH that aborts
after a few cycles.
This input specifies a halting program as other correct simulators and
direct execution prove.

We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.

As usual a false claim.
Your huge mistake is you claim that if HHH cannot be corrected, then HHH
must be correct.
If something cannot be corrected, that does not prove that it is correct.
Using simulation is just the incorrect tool for this problem. A
simulator must fail when it tries to simulate itself, because it cannot possible simulate itself correctly up to the end.
We know that for a larger number HHH will be able to correctly analyse
this input, but then we can construct another DDD, based on the new HHH,
for which HHH will fail again.
This only proves the correctness of the halting theorem. No decider
exists that correctly decides about the halting behaviour of all
possible inputs.

https://github.com/plolcott/x86utm/blob/master/Halt7.c

Failing to do that proves that you are wrong.

As usual incorrect claims without evidence.

Because we have been over this so many times I am
convinced that you already know that you are wrong
and are just trolling me.

You may close your eyes again and pretend that the errors in your logic
do not eist. Very childish.

There is no stack unwinding when HHH sees DDD calls the
same function with the same parameter twice in sequence.
At this point HHH kills the whole DDD process including
all recursive emulations.

In this case the parameter of DDD is irrelevant. HHH should take into
account the state changes in the simulated HHH, which influence its conditional branch instructions.

based on the wrong assumption that a finite recursion specifies non-
halting.

Halting is defined as reaching the "return" statement
final halt state. It is not defined as stopping running
for any reason otherwise both of these would be determined
to be halting:

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

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

More relevant is:

void Finite_Recursion () {
int N = 5;
if (N > 0) Finite_Recursion ();
printf ("Olcott thinks this is never printed.\n");
}

Even if this when this function is called twice in succession without
any changed parameter, there is no infinite recursion.
The same happens inside HHH, where a count is maintained of calls to
DDD. This count influences the conditional branch instructions within HHH.

Because they stop running as soon as their process it killed.

Irrelevant.

Then the simulating HHH does reach its own halt state when it reports
non-halting.

Yet neither the simulated DDD nor the simulated HHH
can possibly reach their own final halt state

Only because the simulating HHH prevents them to do so by the premature
abort. Without the premature abort, they do reach their final halt
state, as proven by other world-class simulators.

The simulated HHH, that has a similar final halt state after it aborts,

The simulated HHH cannot possibly abort because the directly
executed HHH is always one whole recursive simulation ahead
thus reaching its abort criteria first.

Indeed, the simulating HHH prevents the simulated HHH to reach its final
halt state.

After HHH sees that its simulated DDD is calling the same
function with the same parameter twice in sequence it kills
the whole simulated process. Even if it waited to see this
35 times in sequence the next inner one would have only seen
it 34 times, thus has not met its own abort criteria.

Counter factual. When HHH would wait 3 times, it would see that the
simulated HHH aborts after 2 cycles for this input with a HHH that
aborts after 2 cycles.
But you are cheating by also changing the input, so that now it requires
36 cycles.

does not reach it own final halt state, because the simulating HHH
does not allow it to reach it by the premature abort done by the
simulating HHH.

You cannot prove that your use of the term "premature abort"
is anything besides a misconception. *See above challenge*

I have proven it, but you close your eyes for it and claim it does not
exist.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 8/1/2025 4:00 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 16:52 schreef olcott:

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

Op 30.jul.2025 om 05:12 schreef olcott:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*

Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.

Indeed. But there are different reasons:
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,

*I challenge you to show a premature abort*

This has been presented tro you many times, but you close your eyes for
it and pretend that it does not exist.>

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

We have told you that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all function called by DDD, directly or indirectly, including the HHH that aborts
after a few cycles.
This input specifies a halting program as other correct simulators and direct execution prove.

Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.

Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.

We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.

As usual a false claim.

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

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

If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 8/1/25 11:12 AM, olcott wrote:

On 8/1/2025 4:00 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 16:52 schreef olcott:

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

Op 30.jul.2025 om 05:12 schreef olcott:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*

Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.

Indeed. But there are different reasons:
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,

*I challenge you to show a premature abort*

This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>

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

We have told you that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH that
aborts after a few cycles.
This input specifies a halting program as other correct simulators and
direct execution prove.

Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.

But since you HHH does abort the simulation of its input, that is an
irrelvent fact.

Just like making a proof that begins with, if pi was 3.

Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.

I guess you are just admitting that your repesentation system is incorrect.

THe "behavior of their input" is DEFINED to be the behavior of the
program the input represents, so if it isn't, that just means you
started with a bad representation.

Maybe you need to learn to do thing right, and not just assume you can
guess about things.

All you are doing is proving your stupidity.

We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.

As usual a false claim.

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

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

If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

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

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

If there is an actual *premature abort* then there is a specific point
in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third
recursive simulation.

Everyone keeps dishonestly changing my words from
(a) DDD correctly simulated by HHH (can't possibly halt)
(b) The directly executed DDD (that halts).

Turing machine deciders do not have directly executed
Turing machines in their domain. They only have finite
string machine description in their domain.

This means that when the behavior specified by the correct
simulation of the input disagrees with the behavior of the
direct execution of DDD() it is the behavior specified by
the input that overrules and supersedes.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 8/1/25 11:44 AM, olcott wrote:

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

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

If there is an actual *premature abort* then there is a specific point
in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third
recursive simulation.

Everyone keeps dishonestly changing my words from
(a) DDD correctly simulated by HHH (can't possibly halt)

No, it is that THIS HHH doesn't correctly simulate THIS DDD,

And your Hypothetical HHH that does the correct simulation, isn't doing
it to THIS DDD, but a different hypothetical one built on it.

You just don't understand (or just blantently lie) what a program is, or
why the input needs to be one.

(b) The directly executed DDD (that halts).

Because that is the actual criteria that Halt Deciders MUST use.

Anything else is just a strawman.

Turing machine deciders do not have directly executed
Turing machines in their domain. They only have finite
string machine description in their domain.

Sure they do, via the concept of REPRESENTATION.

I guess you don't think you can use your computer to watch viedo (lke
the kiddie porn you were caught with)or listen to audio, or process
text, since none of those is actually 0s and 1s like the physical
computers process

This means that when the behavior specified by the correct
simulation of the input disagrees with the behavior of the
direct execution of DDD() it is the behavior specified by
the input that overrules and supersedes.

Nope, just shows you are just a stupid liar that doesn't understand what
he is talking about.

The CORRECT SIMULATION of the CORRECT REPRESENTATION of a program will
exactly match the behavior of that program when run.

That is the behavior that that input represents to a Halt Decider.

So, you are just proving your self to be a stupid liar.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 8/1/2025 11:00 AM, Richard Damon wrote:

On 8/1/25 11:44 AM, olcott wrote:

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

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

If there is an actual *premature abort* then there is a specific point >>>> in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third
recursive simulation.

Everyone keeps dishonestly changing my words from
(a) DDD correctly simulated by HHH (can't possibly halt)

No, it is that THIS HHH doesn't correctly simulate THIS DDD,

The outermost directly executed HHH does correctly
simulate N instructions of DDD and an instance of
itself in the same separate process context that it
created for DDD.

The correctly simulated instance of itself creates
yet another process context to simulate its own
instance of DDD.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 8/1/25 12:51 PM, olcott wrote:

On 8/1/2025 11:00 AM, Richard Damon wrote:

On 8/1/25 11:44 AM, olcott wrote:

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

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

If there is an actual *premature abort* then there is a specific point >>>>> in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third
recursive simulation.

Everyone keeps dishonestly changing my words from
(a) DDD correctly simulated by HHH (can't possibly halt)

No, it is that THIS HHH doesn't correctly simulate THIS DDD,

The outermost directly executed HHH does correctly
simulate N instructions of DDD and an instance of
itself in the same separate process context that it
created for DDD.

The correctly simulated instance of itself creates
yet another process context to simulate its own
instance of DDD.

And N < M, the number of instructions that the program described will
run for.

Since the unaborted process created from the input will halt, it is halting.

The fact that HHH aborts it before you get there doesn't change that fact.

Your problem is you don't understand that only N steps correctly
simulated is not a Correct Simulation, becuase you lie to yourself that
it can be defined that way.

Sorry, your lake bottom retreat awaits you.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

Op 01.aug.2025 om 17:12 schreef olcott:

On 8/1/2025 4:00 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 16:52 schreef olcott:

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

Op 30.jul.2025 om 05:12 schreef olcott:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*

Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.

Indeed. But there are different reasons:
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,

*I challenge you to show a premature abort*

This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>

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

We have told you that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH that
aborts after a few cycles.
This input specifies a halting program as other correct simulators and
direct execution prove.

Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.

It is an irrelevant change of subject to imagine a hypothetical
non-input that has no abort code.

Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.

No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.

We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.

As usual a false claim.

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

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

If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.

Illogical, counter-factual and incorrect claim without evidence.
It is exactly the premature abort that causes that the final halt state
is not reached. Of, course the trace of that prematurely aborted
simulation does not show the last part of a correct simulation.
But a comparison with a correct simulation done by e.g. HHH1, shows the
exact point where the final halt state is reached and where HHH does the premature abort.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

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

Op 01.aug.2025 om 17:12 schreef olcott:

On 8/1/2025 4:00 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 16:52 schreef olcott:

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

Op 30.jul.2025 om 05:12 schreef olcott:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*

Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.

Indeed. But there are different reasons:
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,

*I challenge you to show a premature abort*

This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>

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

We have told you that the suggestion that these 18 bytes are the
whole input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH
that aborts after a few cycles.
This input specifies a halting program as other correct simulators
and direct execution prove.

Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.

It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.

*Not according to the leading author of theory of computation textbooks*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then

H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.

No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.

Where the Hell are you getting that from?

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

Prove your statement on this code.

We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.

As usual a false claim.

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

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

If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.

Illogical, counter-factual and incorrect claim without evidence.

What do you mean by premature abort?
The actual word "premature" means too early.
If the abort is too early then there is a point
in the execution trace that is not too early.

It is exactly the premature abort that causes that the final halt state
is not reached. Of, course the trace of that prematurely aborted
simulation does not show the last part of a correct simulation.

In other words when DDD calls its own simulator HHH in
recursive simulation this is exactly the same thing as
DDD never calling its own simulator HHH1 in recursive
simulation?

Sounds like 1984 newspeak to me.
https://en.wikipedia.org/wiki/Newspeak

But a comparison with a correct simulation done by e.g. HHH1, shows the exact point where the final halt state is reached and where HHH does the premature abort.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 8/2/25 10:27 AM, olcott wrote:

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

Op 01.aug.2025 om 17:12 schreef olcott:

On 8/1/2025 4:00 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 16:52 schreef olcott:

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

Op 30.jul.2025 om 05:12 schreef olcott:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*

Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.

Indeed. But there are different reasons:
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,

*I challenge you to show a premature abort*

This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>

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

We have told you that the suggestion that these 18 bytes are the
whole input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH
that aborts after a few cycles.
This input specifies a halting program as other correct simulators
and direct execution prove.

Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.

It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.

*Not according to the leading author of theory of computation textbooks*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its
    input D until H correctly determines that its simulated D
    would never stop running unless aborted then

    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.

No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.

Where the Hell are you getting that from?

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

Prove your statement on this code.

We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.

As usual a false claim.

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

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

If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.

Illogical, counter-factual and incorrect claim without evidence.

What do you mean by premature abort?
The actual word "premature" means too early.
If the abort is too early then there is a point
in the execution trace that is not too early.

And that would be when the final state is found, or an ACTUAL PROOF of non-halting can be made. Your "proof" fails, as it looks at a different
input, the DDD that calls the non-aborting HHH.

It is exactly the premature abort that causes that the final halt
state is not reached. Of, course the trace of that prematurely aborted
simulation does not show the last part of a correct simulation.

In other words when DDD calls its own simulator HHH in
recursive simulation this is exactly the same thing as
DDD never calling its own simulator HHH1 in recursive
simulation?

Right, becuase in both cases it calls the exact same program HHH.

It doesn't CARE who is simulating it, as simulation is objective, and
thus doesn't matter who does it.

IF you want to try to show why it matters, show what instruciton changed behavior per the x86 language.

Your failure has shown your stupidity.

Sounds like 1984 newspeak to me.
https://en.wikipedia.org/wiki/Newspeak

Nope, YOURS does, as you seem to think that something that doesn't
matter is the most important thing in the world.

But a comparison with a correct simulation done by e.g. HHH1, shows
the exact point where the final halt state is reached and where HHH
does the premature abort.

--- Synchronet 3.21a-Linux NewsLink 1.2