On 6/6/2025 11:06 AM, Mike Terry wrote:
On 05/06/2025 05:27, olcott wrote:
On 6/4/2025 10:55 PM, Mike Terry wrote:
On 05/06/2025 02:39, olcott wrote:
On 6/4/2025 8:28 PM, dbush wrote:
On 6/4/2025 9:08 PM, olcott wrote:
On 6/4/2025 7:41 PM, dbush wrote:
On 6/4/2025 8:32 PM, olcott wrote:
See below, which shows that the simulations performed by HHH and >>>>>>>> HHH1 are identical up to the point that HHH aborts, as you have >>>>>>>> agreed on the record.
Show me this side-by-side trace and I will point out your mistake. >>>>>>>>
False. The correct trace is the one I posted, which shows all
levels of emulation performed by HHH and HHH1. See the
corrections I made to your comments
It is not supposed to do that.
Are you saying it's not supposed to include /nested/ emulations? It
is perfectly sensible to include nested emulations.
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side.
A side-by-side analysis must be side-by-side.
Hierarchies can be compared side-by-side. In the case of these
traces, the hierarchy can be "flattened" into one stream of nested
simulations. You do this yourself every time you present one of your
nested simulation traces. Such a trace should include a simulation
depth (or equivalent) for each entry.
Two nested simulation traces can easily be presented side-by-side for
comparisson. You are just trying to divert attention from your own
failings to properly understand the requirements.
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1 DDD emulated by HHH
[00002183] push ebp [00002183] push ebp [00002184] mov ebp,esp [00002184] mov ebp,esp [00002186] push 00002183 ; DDD [00002186] push 00002183 ; DDD [0000218b] call 000015c3 ; HHH [0000218b] call 000015c3 ; HHH
*HHH1 emulates DDD once then HHH emulates DDD once, these match*
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS*
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS*
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS*
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS*
DDD emulated by HHH emulating itself
[00002183] push ebp ;
[00002184] mov ebp,esp ;
[00002186] push 00002183 ; DDD
[0000218b] call 000015c3 ; HHH =================================================================
_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH
[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]
_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1
[000021b0] 83c404 add esp,+04
[000021b3] 33c0 xor eax,eax
[000021b5] 5d pop ebp
[000021b6] c3 ret
Size in bytes:(0020) [000021b6]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== =============
<main is executed>
[000021a3][0010382d][00000000] 55 push ebp ; main() [000021a4][0010382d][00000000] 8bec mov ebp,esp ; main() [000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD [000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
</main is executed>
New slave_stack at:1038d1
Begin Local Halt Decider Simulation Execution Trace Stored at:1138d9
<DDD emulated by HHH1>
[00002183][001138c9][001138cd] 55 push ebp ; DDD of HHH1
[00002184][001138c9][001138cd] 8bec mov ebp,esp ; DDD of HHH1 [00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
</DDD emulated by HHH1>
New slave_stack at:14e2f9
Begin Local Halt Decider Simulation Execution Trace Stored at:15e301
<DDD emulated by HHH>
[00002183][0015e2f1][0015e2f5] 55 push ebp ; DDD of HHH[0]
[00002184][0015e2f1][0015e2f5] 8bec mov ebp,esp ; DDD of HHH[0]
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD [0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
<DDD emulated by HHH>
New slave_stack at:198d21 DDD emulated by HHH
*This is the beginning of the divergence of the behavior*
*HHH is emulating itself emulating DDD, HHH1 never does that*
<DDD emulated by HHH emulating itself>
[00002183][001a8d19][001a8d1d] 55 push ebp ; DDD of HHH[1]
[00002184][001a8d19][001a8d1d] 8bec mov ebp,esp ; DDD of HHH[1]
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD [0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
</DDD emulated by HHH emulating itself>
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
HHH returns to caller
<DDD emulated by HHH1>
[00002190][001138c9][001138cd] 83c404 add esp,+04 ; DDD of HHH1 [00002193][001138cd][000015a8] 5d pop ebp ; DDD of HHH1
[00002194][001138d1][0003a980] c3 ret ; DDD of HHH1
</DDD emulated by HHH1>
<main is executed>
[000021b0][0010382d][00000000] 83c404 add esp,+04 ; main() [000021b3][0010382d][00000000] 33c0 xor eax,eax ; main() [000021b5][00103831][00000018] 5d pop ebp ; main() [000021b6][00103835][00000000] c3 ret ; main()
</main is executed>
Number of Instructions Executed(352831) == 5266 Pages
On 6/6/2025 9:02 PM, Richard Damon wrote:
On 6/6/25 12:53 PM, olcott wrote:
On 6/6/2025 11:06 AM, Mike Terry wrote:
On 05/06/2025 05:27, olcott wrote:
On 6/4/2025 10:55 PM, Mike Terry wrote:
On 05/06/2025 02:39, olcott wrote:
On 6/4/2025 8:28 PM, dbush wrote:
On 6/4/2025 9:08 PM, olcott wrote:
On 6/4/2025 7:41 PM, dbush wrote:
On 6/4/2025 8:32 PM, olcott wrote:
Show me this side-by-side trace and I will point out your >>>>>>>>>>> mistake.
See below, which shows that the simulations performed by HHH >>>>>>>>>> and HHH1 are identical up to the point that HHH aborts, as you >>>>>>>>>> have agreed on the record.
False. The correct trace is the one I posted, which shows all >>>>>>>> levels of emulation performed by HHH and HHH1. See the
corrections I made to your comments
It is not supposed to do that.
Are you saying it's not supposed to include /nested/ emulations?
It is perfectly sensible to include nested emulations.
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side.
A side-by-side analysis must be side-by-side.
Hierarchies can be compared side-by-side. In the case of these
traces, the hierarchy can be "flattened" into one stream of nested
simulations. You do this yourself every time you present one of your
nested simulation traces. Such a trace should include a simulation
depth (or equivalent) for each entry.
Two nested simulation traces can easily be presented side-by-side
for comparisson. You are just trying to divert attention from your
own failings to properly understand the requirements.
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1 DDD emulated by HHH
[00002183] push ebp [00002183] push ebp
[00002184] mov ebp,esp [00002184] mov ebp,esp
[00002186] push 00002183 ; DDD [00002186] push 00002183 ; DDD
[0000218b] call 000015c3 ; HHH [0000218b] call 000015c3 ; HHH
*HHH1 emulates DDD once then HHH emulates DDD once, these match*
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS*
Because the correct emulation of the input doesn't call for this to be
done, and the identity of the emulator doesn't affect the defintion of
a correct emulation.
That fact that NONE of your traces actually show a correct emulation,
I have corrected you on this hundreds of times and
you keep "forgetting" what I said.
On 6/7/2025 6:18 AM, Richard Damon wrote:
On 6/6/25 11:43 PM, olcott wrote:
On 6/6/2025 9:02 PM, Richard Damon wrote:
On 6/6/25 12:53 PM, olcott wrote:
On 6/6/2025 11:06 AM, Mike Terry wrote:
On 05/06/2025 05:27, olcott wrote:
On 6/4/2025 10:55 PM, Mike Terry wrote:
On 05/06/2025 02:39, olcott wrote:
On 6/4/2025 8:28 PM, dbush wrote:
On 6/4/2025 9:08 PM, olcott wrote:
On 6/4/2025 7:41 PM, dbush wrote:
On 6/4/2025 8:32 PM, olcott wrote:
Show me this side-by-side trace and I will point out your >>>>>>>>>>>>> mistake.
See below, which shows that the simulations performed by HHH >>>>>>>>>>>> and HHH1 are identical up to the point that HHH aborts, as >>>>>>>>>>>> you have agreed on the record.
False. The correct trace is the one I posted, which shows all >>>>>>>>>> levels of emulation performed by HHH and HHH1. See the
corrections I made to your comments
It is not supposed to do that.
Are you saying it's not supposed to include /nested/ emulations? >>>>>>>> It is perfectly sensible to include nested emulations.
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side.
A side-by-side analysis must be side-by-side.
Hierarchies can be compared side-by-side. In the case of these
traces, the hierarchy can be "flattened" into one stream of nested >>>>>> simulations. You do this yourself every time you present one of
your nested simulation traces. Such a trace should include a
simulation depth (or equivalent) for each entry.
Two nested simulation traces can easily be presented side-by-side
for comparisson. You are just trying to divert attention from
your own failings to properly understand the requirements.
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1 DDD emulated by HHH
[00002183] push ebp [00002183] push ebp
[00002184] mov ebp,esp [00002184] mov ebp,esp
[00002186] push 00002183 ; DDD [00002186] push 00002183 ; DDD
[0000218b] call 000015c3 ; HHH [0000218b] call 000015c3 ; HHH
*HHH1 emulates DDD once then HHH emulates DDD once, these match*
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS*
Because the correct emulation of the input doesn't call for this to
be done, and the identity of the emulator doesn't affect the
defintion of a correct emulation.
That fact that NONE of your traces actually show a correct emulation,
I have corrected you on this hundreds of times and
you keep "forgetting" what I said.
That you have an "excuse" doesn't change the fact that the traces
shown are not correct.
*No actual error has ever been pointed out*
One of the incoherent notions of error that you
have proposed is that a non-terminating input
was not simulated to completion.
\Just because YOU are to stupid to make sense of the long report,
doesn't mean that it isn't factual, and NEEDED to make your point.
As soon as I detect the first fatal error I quit reading.
All you are doing is saying that logic needs to allow LYING for you to
understand it, likely because you have an inherent misunderstanding
about the nature of how truth and logic work.
Note, you can't even seem to keep seperate the trace of the execution
of the outer HHH from the trace that it sees from its emulation, which
is why the output is so long.
There is no need for the 5226 pages of the traces of
HHH1 and HHH. As soon as main() calls HHH1(DDD) we can
know that HHH1(DDD) has been called.
The problem is that you just don't understand what you are doing, and
are just hacking at a program you jury-rigged from an good open-source
prject that you hacked up to build your "proof" from, by figuing out
how to "edit" its output to show what you want.
Whenever you try to get specific then it is obvious
that all you have is incoherent gibberish.
On 6/7/2025 6:38 PM, Richard Damon wrote:
On 6/7/25 10:13 AM, olcott wrote:
On 6/7/2025 6:18 AM, Richard Damon wrote:
On 6/6/25 11:43 PM, olcott wrote:
On 6/6/2025 9:02 PM, Richard Damon wrote:
On 6/6/25 12:53 PM, olcott wrote:I have corrected you on this hundreds of times and
On 6/6/2025 11:06 AM, Mike Terry wrote:
On 05/06/2025 05:27, olcott wrote:
On 6/4/2025 10:55 PM, Mike Terry wrote:
On 05/06/2025 02:39, olcott wrote:
On 6/4/2025 8:28 PM, dbush wrote:
On 6/4/2025 9:08 PM, olcott wrote:
On 6/4/2025 7:41 PM, dbush wrote:
On 6/4/2025 8:32 PM, olcott wrote:
Show me this side-by-side trace and I will point out your >>>>>>>>>>>>>>> mistake.
See below, which shows that the simulations performed by >>>>>>>>>>>>>> HHH and HHH1 are identical up to the point that HHH >>>>>>>>>>>>>> aborts, as you have agreed on the record.
False. The correct trace is the one I posted, which shows >>>>>>>>>>>> all levels of emulation performed by HHH and HHH1. See the >>>>>>>>>>>> corrections I made to your comments
It is not supposed to do that.
Are you saying it's not supposed to include /nested/
emulations? It is perfectly sensible to include nested
emulations.
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side.
A side-by-side analysis must be side-by-side.
Hierarchies can be compared side-by-side. In the case of these >>>>>>>> traces, the hierarchy can be "flattened" into one stream of
nested simulations. You do this yourself every time you present >>>>>>>> one of your nested simulation traces. Such a trace should
include a simulation depth (or equivalent) for each entry.
Two nested simulation traces can easily be presented side-by-
side for comparisson. You are just trying to divert attention >>>>>>>> from your own failings to properly understand the requirements. >>>>>>>>
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1 DDD emulated by HHH >>>>>>> [00002183] push ebp [00002183] push ebp >>>>>>> [00002184] mov ebp,esp [00002184] mov ebp,esp >>>>>>> [00002186] push 00002183 ; DDD [00002186] push 00002183 ; DDD >>>>>>> [0000218b] call 000015c3 ; HHH [0000218b] call 000015c3 ; HHH >>>>>>> *HHH1 emulates DDD once then HHH emulates DDD once, these match* >>>>>>>
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS*
Because the correct emulation of the input doesn't call for this
to be done, and the identity of the emulator doesn't affect the
defintion of a correct emulation.
That fact that NONE of your traces actually show a correct emulation, >>>>>
you keep "forgetting" what I said.
That you have an "excuse" doesn't change the fact that the traces
shown are not correct.
*No actual error has ever been pointed out*
One of the incoherent notions of error that you
have proposed is that a non-terminating input
was not simulated to completion.
No, it just that you don't seem to understand the concept that a
partial simulation not reaching a final state doesn't establish non-
halting.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
On 6/8/2025 6:11 AM, Richard Damon wrote:No, it does not. It decides too early. It needs three cycles to see the
On 6/7/25 7:54 PM, olcott wrote:
On 6/7/2025 6:38 PM, Richard Damon wrote:
On 6/7/25 10:13 AM, olcott wrote:
On 6/7/2025 6:18 AM, Richard Damon wrote:
On 6/6/25 11:43 PM, olcott wrote:
On 6/6/2025 9:02 PM, Richard Damon wrote:
On 6/6/25 12:53 PM, olcott wrote:
On 6/6/2025 11:06 AM, Mike Terry wrote:Because the correct emulation of the input doesn't call for this >>>>>>>> to be done, and the identity of the emulator doesn't affect the >>>>>>>> defintion of a correct emulation.
On 05/06/2025 05:27, olcott wrote:
On 6/4/2025 10:55 PM, Mike Terry wrote:
On 05/06/2025 02:39, olcott wrote:
On 6/4/2025 8:28 PM, dbush wrote:
On 6/4/2025 9:08 PM, olcott wrote:
On 6/4/2025 7:41 PM, dbush wrote:
On 6/4/2025 8:32 PM, olcott wrote:
Show me this side-by-side trace and I will point out >>>>>>>>>>>>>>>>> your mistake.
See below, which shows that the simulations performed by >>>>>>>>>>>>>>>> HHH and HHH1 are identical up to the point that HHH >>>>>>>>>>>>>>>> aborts, as you have agreed on the record.
False. The correct trace is the one I posted, which shows >>>>>>>>>>>>>> all levels of emulation performed by HHH and HHH1. See >>>>>>>>>>>>>> the corrections I made to your comments
It is not supposed to do that.
Are you saying it's not supposed to include /nested/
emulations? It is perfectly sensible to include nested >>>>>>>>>>>> emulations.
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side.
A side-by-side analysis must be side-by-side.
Hierarchies can be compared side-by-side. In the case of >>>>>>>>>> these traces, the hierarchy can be "flattened" into one stream >>>>>>>>>> of nested simulations. You do this yourself every time you >>>>>>>>>> present one of your nested simulation traces. Such a trace >>>>>>>>>> should include a simulation depth (or equivalent) for each entry. >>>>>>>>>>
Two nested simulation traces can easily be presented side-by- >>>>>>>>>> side for comparisson. You are just trying to divert attention >>>>>>>>>> from your own failings to properly understand the requirements. >>>>>>>>>>
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1 DDD emulated by HHH >>>>>>>>> [00002183] push ebp [00002183] push ebp >>>>>>>>> [00002184] mov ebp,esp [00002184] mov ebp,esp >>>>>>>>> [00002186] push 00002183 ; DDD [00002186] push 00002183 ; DDD >>>>>>>>> [0000218b] call 000015c3 ; HHH [0000218b] call 000015c3 ; HHH >>>>>>>>> *HHH1 emulates DDD once then HHH emulates DDD once, these match* >>>>>>>>>
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS* >>>>>>>>
That fact that NONE of your traces actually show a correct
emulation,
I have corrected you on this hundreds of times and
you keep "forgetting" what I said.
That you have an "excuse" doesn't change the fact that the traces
shown are not correct.
*No actual error has ever been pointed out*
One of the incoherent notions of error that you
have proposed is that a non-terminating input
was not simulated to completion.
No, it just that you don't seem to understand the concept that a
partial simulation not reaching a final state doesn't establish non-
halting.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Right, but the subject of said proposition is the MACHINE, not a
partial simulation of said machine.
For simulations to be used to show non-halting, you must show that
even after an unbounded number of steps simulated, it never reaches a
final state.
We have been over this too many times, either you are
a liar or you have severe brain damage. DDD simulated
by HHH matches a non-halting behavior pattern after
two complete simulations of its first four steps.
On 6/8/2025 6:11 AM, Richard Damon wrote:
On 6/7/25 7:54 PM, olcott wrote:
On 6/7/2025 6:38 PM, Richard Damon wrote:
On 6/7/25 10:13 AM, olcott wrote:
On 6/7/2025 6:18 AM, Richard Damon wrote:
On 6/6/25 11:43 PM, olcott wrote:
On 6/6/2025 9:02 PM, Richard Damon wrote:
On 6/6/25 12:53 PM, olcott wrote:
On 6/6/2025 11:06 AM, Mike Terry wrote:Because the correct emulation of the input doesn't call for this >>>>>>>> to be done, and the identity of the emulator doesn't affect the >>>>>>>> defintion of a correct emulation.
On 05/06/2025 05:27, olcott wrote:
On 6/4/2025 10:55 PM, Mike Terry wrote:
On 05/06/2025 02:39, olcott wrote:
On 6/4/2025 8:28 PM, dbush wrote:
On 6/4/2025 9:08 PM, olcott wrote:
On 6/4/2025 7:41 PM, dbush wrote:
On 6/4/2025 8:32 PM, olcott wrote:
Show me this side-by-side trace and I will point out >>>>>>>>>>>>>>>>> your mistake.
See below, which shows that the simulations performed by >>>>>>>>>>>>>>>> HHH and HHH1 are identical up to the point that HHH >>>>>>>>>>>>>>>> aborts, as you have agreed on the record.
False. The correct trace is the one I posted, which shows >>>>>>>>>>>>>> all levels of emulation performed by HHH and HHH1. See >>>>>>>>>>>>>> the corrections I made to your comments
It is not supposed to do that.
Are you saying it's not supposed to include /nested/
emulations? It is perfectly sensible to include nested >>>>>>>>>>>> emulations.
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side.
A side-by-side analysis must be side-by-side.
Hierarchies can be compared side-by-side. In the case of >>>>>>>>>> these traces, the hierarchy can be "flattened" into one stream >>>>>>>>>> of nested simulations. You do this yourself every time you >>>>>>>>>> present one of your nested simulation traces. Such a trace >>>>>>>>>> should include a simulation depth (or equivalent) for each entry. >>>>>>>>>>
Two nested simulation traces can easily be presented side-by- >>>>>>>>>> side for comparisson. You are just trying to divert attention >>>>>>>>>> from your own failings to properly understand the requirements. >>>>>>>>>>
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1 DDD emulated by HHH >>>>>>>>> [00002183] push ebp [00002183] push ebp >>>>>>>>> [00002184] mov ebp,esp [00002184] mov ebp,esp >>>>>>>>> [00002186] push 00002183 ; DDD [00002186] push 00002183 ; DDD >>>>>>>>> [0000218b] call 000015c3 ; HHH [0000218b] call 000015c3 ; HHH >>>>>>>>> *HHH1 emulates DDD once then HHH emulates DDD once, these match* >>>>>>>>>
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS* >>>>>>>>
That fact that NONE of your traces actually show a correct
emulation,
I have corrected you on this hundreds of times and
you keep "forgetting" what I said.
That you have an "excuse" doesn't change the fact that the traces
shown are not correct.
*No actual error has ever been pointed out*
One of the incoherent notions of error that you
have proposed is that a non-terminating input
was not simulated to completion.
No, it just that you don't seem to understand the concept that a
partial simulation not reaching a final state doesn't establish non-
halting.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Right, but the subject of said proposition is the MACHINE, not a
partial simulation of said machine.
For simulations to be used to show non-halting, you must show that
even after an unbounded number of steps simulated, it never reaches a
final state.
We have been over this too many times, either you are
a liar or you have severe brain damage. DDD simulated
by HHH matches a non-halting behavior pattern after
two complete simulations of its first four steps.
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 6/8/2025 12:17 PM, Fred. Zwarts wrote:
Op 08.jun.2025 om 18:41 schreef olcott:
On 6/8/2025 6:11 AM, Richard Damon wrote:
On 6/7/25 7:54 PM, olcott wrote:
On 6/7/2025 6:38 PM, Richard Damon wrote:
On 6/7/25 10:13 AM, olcott wrote:
On 6/7/2025 6:18 AM, Richard Damon wrote:
On 6/6/25 11:43 PM, olcott wrote:
On 6/6/2025 9:02 PM, Richard Damon wrote:
On 6/6/25 12:53 PM, olcott wrote:
On 6/6/2025 11:06 AM, Mike Terry wrote:Because the correct emulation of the input doesn't call for >>>>>>>>>> this to be done, and the identity of the emulator doesn't
On 05/06/2025 05:27, olcott wrote:
On 6/4/2025 10:55 PM, Mike Terry wrote:
On 05/06/2025 02:39, olcott wrote:
On 6/4/2025 8:28 PM, dbush wrote:
On 6/4/2025 9:08 PM, olcott wrote:
On 6/4/2025 7:41 PM, dbush wrote:
On 6/4/2025 8:32 PM, olcott wrote:
Show me this side-by-side trace and I will point out >>>>>>>>>>>>>>>>>>> your mistake.
See below, which shows that the simulations performed >>>>>>>>>>>>>>>>>> by HHH and HHH1 are identical up to the point that HHH >>>>>>>>>>>>>>>>>> aborts, as you have agreed on the record.
False. The correct trace is the one I posted, which >>>>>>>>>>>>>>>> shows all levels of emulation performed by HHH and HHH1. >>>>>>>>>>>>>>>> See the corrections I made to your comments
It is not supposed to do that.
Are you saying it's not supposed to include /nested/ >>>>>>>>>>>>>> emulations? It is perfectly sensible to include nested >>>>>>>>>>>>>> emulations.
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side. >>>>>>>>>>>>> A side-by-side analysis must be side-by-side.
Hierarchies can be compared side-by-side. In the case of >>>>>>>>>>>> these traces, the hierarchy can be "flattened" into one >>>>>>>>>>>> stream of nested simulations. You do this yourself every >>>>>>>>>>>> time you present one of your nested simulation traces. Such >>>>>>>>>>>> a trace should include a simulation depth (or equivalent) >>>>>>>>>>>> for each entry.
Two nested simulation traces can easily be presented side- >>>>>>>>>>>> by- side for comparisson. You are just trying to divert >>>>>>>>>>>> attention from your own failings to properly understand the >>>>>>>>>>>> requirements.
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1 DDD emulated by HHH >>>>>>>>>>> [00002183] push ebp [00002183] push ebp >>>>>>>>>>> [00002184] mov ebp,esp [00002184] mov ebp,esp >>>>>>>>>>> [00002186] push 00002183 ; DDD [00002186] push 00002183 ; DDD >>>>>>>>>>> [0000218b] call 000015c3 ; HHH [0000218b] call 000015c3 ; HHH >>>>>>>>>>> *HHH1 emulates DDD once then HHH emulates DDD once, these match* >>>>>>>>>>>
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS* >>>>>>>>>>
affect the defintion of a correct emulation.
That fact that NONE of your traces actually show a correct >>>>>>>>>> emulation,
I have corrected you on this hundreds of times and
you keep "forgetting" what I said.
That you have an "excuse" doesn't change the fact that the
traces shown are not correct.
*No actual error has ever been pointed out*
One of the incoherent notions of error that you
have proposed is that a non-terminating input
was not simulated to completion.
No, it just that you don't seem to understand the concept that a
partial simulation not reaching a final state doesn't establish
non- halting.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Right, but the subject of said proposition is the MACHINE, not a
partial simulation of said machine.
For simulations to be used to show non-halting, you must show that
even after an unbounded number of steps simulated, it never reaches
a final state.
We have been over this too many times, either you are
a liar or you have severe brain damage. DDD simulated
by HHH matches a non-halting behavior pattern after
two complete simulations of its first four steps.
No, it does not. It decides too early. It needs three cycles to see
the halting behaviour.
All you have is a lack of sufficient technical competence.
It needs to simulate more that the first four steps. It also needs to
count the conditional branch instructions in HHH.
On 6/8/2025 12:27 PM, Richard Damon wrote:
On 6/8/25 12:41 PM, olcott wrote:
On 6/8/2025 6:11 AM, Richard Damon wrote:
On 6/7/25 7:54 PM, olcott wrote:
On 6/7/2025 6:38 PM, Richard Damon wrote:
On 6/7/25 10:13 AM, olcott wrote:
On 6/7/2025 6:18 AM, Richard Damon wrote:
On 6/6/25 11:43 PM, olcott wrote:
On 6/6/2025 9:02 PM, Richard Damon wrote:
On 6/6/25 12:53 PM, olcott wrote:
On 6/6/2025 11:06 AM, Mike Terry wrote:Because the correct emulation of the input doesn't call for >>>>>>>>>> this to be done, and the identity of the emulator doesn't
On 05/06/2025 05:27, olcott wrote:
On 6/4/2025 10:55 PM, Mike Terry wrote:
On 05/06/2025 02:39, olcott wrote:
On 6/4/2025 8:28 PM, dbush wrote:
On 6/4/2025 9:08 PM, olcott wrote:
On 6/4/2025 7:41 PM, dbush wrote:
On 6/4/2025 8:32 PM, olcott wrote:
Show me this side-by-side trace and I will point out >>>>>>>>>>>>>>>>>>> your mistake.
See below, which shows that the simulations performed >>>>>>>>>>>>>>>>>> by HHH and HHH1 are identical up to the point that HHH >>>>>>>>>>>>>>>>>> aborts, as you have agreed on the record.
False. The correct trace is the one I posted, which >>>>>>>>>>>>>>>> shows all levels of emulation performed by HHH and HHH1. >>>>>>>>>>>>>>>> See the corrections I made to your comments
It is not supposed to do that.
Are you saying it's not supposed to include /nested/ >>>>>>>>>>>>>> emulations? It is perfectly sensible to include nested >>>>>>>>>>>>>> emulations.
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side. >>>>>>>>>>>>> A side-by-side analysis must be side-by-side.
Hierarchies can be compared side-by-side. In the case of >>>>>>>>>>>> these traces, the hierarchy can be "flattened" into one >>>>>>>>>>>> stream of nested simulations. You do this yourself every >>>>>>>>>>>> time you present one of your nested simulation traces. Such >>>>>>>>>>>> a trace should include a simulation depth (or equivalent) >>>>>>>>>>>> for each entry.
Two nested simulation traces can easily be presented side- >>>>>>>>>>>> by- side for comparisson. You are just trying to divert >>>>>>>>>>>> attention from your own failings to properly understand the >>>>>>>>>>>> requirements.
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1 DDD emulated by HHH >>>>>>>>>>> [00002183] push ebp [00002183] push ebp >>>>>>>>>>> [00002184] mov ebp,esp [00002184] mov ebp,esp >>>>>>>>>>> [00002186] push 00002183 ; DDD [00002186] push 00002183 ; DDD >>>>>>>>>>> [0000218b] call 000015c3 ; HHH [0000218b] call 000015c3 ; HHH >>>>>>>>>>> *HHH1 emulates DDD once then HHH emulates DDD once, these match* >>>>>>>>>>>
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS* >>>>>>>>>>
affect the defintion of a correct emulation.
That fact that NONE of your traces actually show a correct >>>>>>>>>> emulation,
I have corrected you on this hundreds of times and
you keep "forgetting" what I said.
That you have an "excuse" doesn't change the fact that the
traces shown are not correct.
*No actual error has ever been pointed out*
One of the incoherent notions of error that you
have proposed is that a non-terminating input
was not simulated to completion.
No, it just that you don't seem to understand the concept that a
partial simulation not reaching a final state doesn't establish
non- halting.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Right, but the subject of said proposition is the MACHINE, not a
partial simulation of said machine.
For simulations to be used to show non-halting, you must show that
even after an unbounded number of steps simulated, it never reaches
a final state.
We have been over this too many times, either you are
a liar or you have severe brain damage. DDD simulated
by HHH matches a non-halting behavior pattern after
two complete simulations of its first four steps.
But it doesn't match a correct non-halting behavior pattern,
All you have is a lack of sufficient technical competence.
On 6/8/2025 12:17 PM, Fred. Zwarts wrote:
Op 08.jun.2025 om 18:41 schreef olcott:
On 6/8/2025 6:11 AM, Richard Damon wrote:
On 6/7/25 7:54 PM, olcott wrote:
On 6/7/2025 6:38 PM, Richard Damon wrote:
On 6/7/25 10:13 AM, olcott wrote:
On 6/7/2025 6:18 AM, Richard Damon wrote:
On 6/6/25 11:43 PM, olcott wrote:
On 6/6/2025 9:02 PM, Richard Damon wrote:
On 6/6/25 12:53 PM, olcott wrote:
On 6/6/2025 11:06 AM, Mike Terry wrote:Because the correct emulation of the input doesn't call for >>>>>>>>>> this to be done, and the identity of the emulator doesn't
On 05/06/2025 05:27, olcott wrote:
On 6/4/2025 10:55 PM, Mike Terry wrote:
On 05/06/2025 02:39, olcott wrote:
On 6/4/2025 8:28 PM, dbush wrote:
On 6/4/2025 9:08 PM, olcott wrote:
On 6/4/2025 7:41 PM, dbush wrote:
On 6/4/2025 8:32 PM, olcott wrote:
Show me this side-by-side trace and I will point out >>>>>>>>>>>>>>>>>>> your mistake.
See below, which shows that the simulations performed >>>>>>>>>>>>>>>>>> by HHH and HHH1 are identical up to the point that HHH >>>>>>>>>>>>>>>>>> aborts, as you have agreed on the record.
False. The correct trace is the one I posted, which >>>>>>>>>>>>>>>> shows all levels of emulation performed by HHH and HHH1. >>>>>>>>>>>>>>>> See the corrections I made to your comments
It is not supposed to do that.
Are you saying it's not supposed to include /nested/ >>>>>>>>>>>>>> emulations? It is perfectly sensible to include nested >>>>>>>>>>>>>> emulations.
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side. >>>>>>>>>>>>> A side-by-side analysis must be side-by-side.
Hierarchies can be compared side-by-side. In the case of >>>>>>>>>>>> these traces, the hierarchy can be "flattened" into one >>>>>>>>>>>> stream of nested simulations. You do this yourself every >>>>>>>>>>>> time you present one of your nested simulation traces. Such >>>>>>>>>>>> a trace should include a simulation depth (or equivalent) >>>>>>>>>>>> for each entry.
Two nested simulation traces can easily be presented side- >>>>>>>>>>>> by- side for comparisson. You are just trying to divert >>>>>>>>>>>> attention from your own failings to properly understand the >>>>>>>>>>>> requirements.
*From the execution trace of HHH1(DDD) shown below*
DDD emulated by HHH1 DDD emulated by HHH >>>>>>>>>>> [00002183] push ebp [00002183] push ebp >>>>>>>>>>> [00002184] mov ebp,esp [00002184] mov ebp,esp >>>>>>>>>>> [00002186] push 00002183 ; DDD [00002186] push 00002183 ; DDD >>>>>>>>>>> [0000218b] call 000015c3 ; HHH [0000218b] call 000015c3 ; HHH >>>>>>>>>>> *HHH1 emulates DDD once then HHH emulates DDD once, these match* >>>>>>>>>>>
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS* >>>>>>>>>>
affect the defintion of a correct emulation.
That fact that NONE of your traces actually show a correct >>>>>>>>>> emulation,
I have corrected you on this hundreds of times and
you keep "forgetting" what I said.
That you have an "excuse" doesn't change the fact that the
traces shown are not correct.
*No actual error has ever been pointed out*
One of the incoherent notions of error that you
have proposed is that a non-terminating input
was not simulated to completion.
No, it just that you don't seem to understand the concept that a
partial simulation not reaching a final state doesn't establish
non- halting.
*CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
Right, but the subject of said proposition is the MACHINE, not a
partial simulation of said machine.
For simulations to be used to show non-halting, you must show that
even after an unbounded number of steps simulated, it never reaches
a final state.
We have been over this too many times, either you are
a liar or you have severe brain damage. DDD simulated
by HHH matches a non-halting behavior pattern after
two complete simulations of its first four steps.
No, it does not. It decides too early. It needs three cycles to see
the halting behaviour.
All you have is a lack of sufficient technical competence.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 58:54:35 |
| Calls: | 12,117 |
| Files: | 15,010 |
| Messages: | 6,518,711 |