H(P,P)==0 is proven to be correct thus refuting the halting problem proofs

[olcott]

It is an easily verified fact that the execution trace provided by
H(P,P) of the nested simulation of its input exactly matches the
behavior of the correctly reverse-engineered nested execution trace
would be.

To reverse-engineer this execution trace we only need to step through
the x86 source-code of P and simply hypothesize that H does perform a
pure x86 emulation of its input.

If H did correctly perform a pure x86 emulation of P then these first
instructions of P would be executed in sequence.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H

The last line of code calls H(P,P) that would of course have to emulate
these same seven instructions again. From this we can see that P would
never reach its own final state at [0000136c]. When "halting" is defined
as reaching a final state we correctly conclude that P is non-halting.

This shows that H(P,P) does match the halting problem proof
counter-example pattern. Instead of source-code that must be
interpreted or compiled the machine language of P is passed to H.

For any program H that might determine if programs
halt, a "pathological" program P, called with some
input, can pass its own source and its input to H
and then specifically do the opposite of what H
predicts P will do. No H can exist that handles this
case. https://en.wikipedia.org/wiki/Halting_problem

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.

...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(15892) = 237 pages

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

[Richard Damon]

On 5/21/22 10:44 AM, olcott wrote:
> It is an easily verified fact that the execution trace provided by
> H(P,P) of the nested simulation of its input exactly matches the
> behavior of the correctly reverse-engineered nested execution trace
> would be.

No, it is easy to verify that it does NOT.

No execution path from P actually CALLS another copy of P, as your trace
implies.

Remember, an execution trace is supposed to show the sequence of
instructions that a CPU would actually execute if we ran the program.

Since H is defined to SIMULATE its input, it isn't actually executed, so
to trace it like it was is just INCORRECT.

>
> To reverse-engineer this execution trace we only need to step through
> the x86 source-code of P and simply hypothesize that H does perform a
> pure x86 emulation of its input.
>

Right, so why don't we see that emulation? H doesn't CALL P, it emulates
it, so reporting as if that was just being executed is just a LIE.

> If H did correctly perform a pure x86 emulation of P then these first
> instructions of P would be executed in sequence.
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
>
> The last line of code calls H(P,P) that would of course have to emulate
> these same seven instructions again. From this we can see that P would
> never reach its own final state at [0000136c]. When "halting" is defined
> as reaching a final state we correctly conclude that P is non-halting.

Right, so we should see the EMULATION of those instructions.

Note, we know that H isn't doing an UNCONDITIONAL emulation of those
instructions, as you have stated that H will abort its simulation of its
input when it detects what it thinks is infinite behavior, so we KNOW
that if we looked at a CORRECT UNCOONDITIONAL simulation of P, we would
see that happen, return the non-halting value to P and P then Halting.

That PROVES that the simulation of P by H is NOT a correct simulation
with a correct decision to abort.

The problem is that P's logic is ignoring the conditionals in the
embedded copy of H, meaning it is using INVALID logic.

>
> This shows that H(P,P) does match the halting problem proof
> counter-example pattern. Instead of source-code that must be
> interpreted or compiled the machine language of P is passed to H.

Nope.

>
>    For any program H that might determine if programs
>    halt, a "pathological" program P, called with some
>    input, can pass its own source and its input to H
>    and then specifically do the opposite of what H
>    predicts P will do. No H can exist that handles this
>    case. https://en.wikipedia.org/wiki/Halting_problem

And since P(P) Halts, and your H(P,P) says it doesn't, your H gives the
wrong answer, so it is NOT a counter example for that statement.

Please show you can read the requirements.

H given the code for P, did NOT correctly determine what P(P) would do.

Thus if FAILED.

Note, trace is incorrect after this point.

But P(P) will Halt, so the answer is WRONG.

[olcott]

On 5/21/2022 10:14 AM, Richard Damon wrote:
>
> On 5/21/22 10:44 AM, olcott wrote:
>> It is an easily verified fact that the execution trace provided by
>> H(P,P) of the nested simulation of its input exactly matches the
>> behavior of the correctly reverse-engineered nested execution trace
>> would be.
>
> No, it is easy to verify that it does NOT.

You know that you are a liar so I challenge you to provide the execution
trace that a pure single level nested emulation of the input to H(P,P)
would be. Any failure to provide this basis for your damned lies will be
considered direct admission that you know you are lying.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

[Richard Damon]

Well, I wopuld need to have the code for H to do that, since that is
PART of P.

It would begin as:

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============

...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]

...[00001358][0021233a][00001352] 50 push eax // push P

...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]

...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

At this point I don't have the data, but it would trace the instructions
that H executes as it simulates its copy of P until it reaches the point
it decides to abort its simulation and return to P

Then it would continue to:

...[00001362][00212332][00001362] 83c408 add esp,+08
...[00001365][0021233a][00001352] 85c0 test eax,eax
...[00001367][0021233a][00001352] 7402 jz 0000136b
...[0000136b][0021233a][00001352] 5d pop ebp
...[0000136c][0021233a][00001352] c3 ret

And P thus Halts.

(Disclaimer, Hand done so typeographical errors may exist)

YOU even have provided the basis of this trace when you published this
equivalent a while back (The trace of H_Hat(H_Hat)

This had the issue that it traces the simulated program that the
simulated H was simulating rather than H itself, but the rest shows what
happens.

> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938

> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

[olcott]

The assumption is that H(P,P) correctly emulates its input.
You are required to show the execution trace of the input to H(P,P)
under that assumption for one emulation and one nested emulation.
The one that you provided for the emulation is correct.

[Richard Damon]

Maybe a bad assumption!

> You are required to show the execution trace of the input to H(P,P)
> under that assumption for one emulation and one nested emulation.
> The one that you provided for the emulation is correct.
>

WHY? That isn't the trace of *A* execution. This is mixing two different
traces, which is a logical error.

Like I said, unless you give me the code for H, how can I show how it
emulates its input.

You are just showing you don't know that a TRACE is supposed to show.

You also are showing you don't understand what a PROOF is.


Your requriement to me is worse than your claim of what we are asking H
to do.

[olcott]

It is stipulated that you must show what the execution trace of the
input to H(P,P) would be if H only simulated its input. You must show
this for one simulation and one nested simulation. Failure to do this
will be construed as a direct admission that you know you are lying.

[olcott]

On 5/21/2022 11:52 AM, Dennis Bush wrote:

> Invalid, since H (i.e. Ha) has a fixed algorithm to abort.

H does not have a fixed algorithm to abort at any point prior to the
first nested simulation, thus you are still required to show what the
correct emulation of the input to H(P,P) would be for one emulation and
one nested emulation. Any failure to do so will be construed as a direct
admission that you know that you are lying.

[Richard Damon]

So, give me a copy of H to trace, since THAT is what should be trace and
actually should be part of the input "byte" stream, but since it is just
a pointer, you can't really tell how long the input is.

The other option is right after the call to H, it needs to print:

*** ERROR: Input is not a computation, went outside its definition ***


But you said that it needs to "succeed".

What you seem to be asking for is the equivalnt of asking for a Cat that
is a Dog, since the two chunks of simulation you seem to be thinking of
are in DIFFERENT execution contexts, and thus aren't part of a single
execution trace.

I suppose another option would be to mark EACH line of the second trace
with a prefix to says SIMULTION OF, and followed by a DECIDED TO
CONTINUE (reason) , or DECIDED TO ABORT (reason).


But this blows the hole in your theory as disclosing the conditional
breaks the rule you are trying to apply, and make it clear that H
doesn't actually have grounds to say that P is in an infinite recursion,
since the rule needs no conditions that might change.


Note, I DID post a couple of messages back (16:22 GMT) a trace from YOUR
system showing a trace in your format of H_Hat(H_Hat) (which you have
now changed to be named P) which seems to be what you are asking for.

Yes, H can't generate such a trace, becuase an H can't be written to get
the right answer.

It DOES show what the "Correct Simulation of the input to H(P,P)" would be.

[olcott]

You are required to provide a trace under the assumption that H(P,P)
only does a pure x86 emulation of its input for the first emulation and
the first nested emulation. Are you too stupid to understand this?

[Richard Damon]

You obviously have an reading problem.

I said, for that I need the code of H, as that is what needs to be traced.

To say otherwise just proves you are s stupid liar,

How else can you show an emulation of an emulator unless you have the
code that is doing the emulation that needs to be shown,

[olcott]

If it is "given" that this code only performs a pure x86 emulation of
its input (unless you have no idea what an x86 emulation is) there is no
reason to see that the code derives a pure x86 emulation of its input.

What a pure x86 emulation of the input would be can be reverse
engineered entirely on the basis of the x86 source code for P.

You are not stupid for not knowing this, instead of stupid you would be
technically unqualified to evaluate my work.

> To say otherwise just proves you are s stupid liar,
>
> How else can you show an emulation of an emulator unless you have the
> code that is doing the emulation that needs to be shown,
>
>

[Richard Damon]

The the trace of the emulation needs to show the actual steps of
emulationg the input, like I mentioned.

If H is actually emulating the code, then the "instructions" of the
second level are never actually executed, are they?

Maybe YOU don't understand what an emulator does.

>
> What a pure x86 emulation of the input would be can be reverse
> engineered entirely on the basis of the x86 source code for P.

And I posted what that would be. It doesn't show a second level of
direct execution, because that is just a LIE.

>
> You are not stupid for not knowing this, instead of stupid you would be
> technically unqualified to evaluate my work.

Nope, you are not technically qualified to make your claims, but you
make them anyway and show your ignorance.

[olcott]

If I showed either the source-code of H or the execution trace of H
people here would be so confused that I would never reach closure in 50
years. If they can't comprehend a 14 line execution trace then showing
them much more than this would permanently scramble their brains.

The proof of technical competence to evaluating my work is understanding
that I have already shown everything that it needed.

Conversely the lack of this understanding is conclusive proof of
insufficient technical competence.

[Richard Damon]

No, people wouldn't be confused,

>
> The proof of technical competence to evaluating my work is understanding
> that I have already shown everything that it needed.

No, you are just proving that you don't know what a proof is. You post
LIES of traces, that people are calling you out on.

>
> Conversely the lack of this understanding is conclusive proof of
> insufficient technical competence.
>

Only of YOU. Someone who claims that no one can understand there work in
the typical sign of someone who is deluded into thinking there false
thinking it correct.

Real Genius can explain it so that most people can understand it. If you
can't do that, it means you don't really understand what you are saying,
since you can't break it down to component parts.

Truth can be broken down into a simple step by step explaination (it
might be long). Fantasy often can't handle that level of examination as
its flaws get reveiled.

Your inability to explain your idea in simpler terms means that you
don't really understand the truth in it.

As you have said, if it is something that can be known, it can be
expresses as an actual proof, starting from the ACCEPTED truths of the
system and then combined with accepted logical operation to reach the
final statement, and thus proving it.

You can't break down your idea to this step by step analysis because it
is based on false premises that you can only try to justfy by keeping
them too complicated.

You claims of "True by the meaning of the words", is a false claim, as
you can't actually quote the meaning of the words (as accepted) to build
up to the claim you want to make.

[olcott]

That they don't understand that they don't need to see this conclusively
proves that they have woefully inadequate technical skills to evaluate
my work.

[Richard Damon]

Just shows you are lying.

I think you are afraid that people DO have the technical skills to
evaluate your work and if you show what you have done you will be
utterly humiliated.

You have taken EXTREAMLY long times to do anything programming related
to this problem, an my guess is that the code quality will show your
incompetence, if you even have actual working code.

You are afraid to release to code, because then you can't keep lying
about what it does. Other people could look at the enourmous trace and
filter it the way THEY want to see what is actually happening and show
the errors you are hidding behind your smoke and mirrors.

If people can't understand your code, then what is the harm with
releasing it? It will then just remain an impenetrable black box.

You are calling people with actual credentials (which you don't have) as
incompetent, while at the same time saying you need their help because
you can't explain your work to write the article.

Either you are being stupid and asking people who can't help, or you are
actually to stupid to know who actually know stuff.

Either way, you are proving your stupidity.

[olcott]

I coined the term "ignorance squared" decades ago to account for the
fact that people cannot possibly be directly aware of their own ignorance.

To be directly aware of their own ignorance requires them to contrast
their ignorance with the knowledge that they are missing.

Since they don't have this missing knowledge they cannot become directly
aware that they are missing any knowledge. Their own ignorance is simply
perceived as disagreement.

[Richard Damon]

You seem tobe a good example of that.

>
> To be directly aware of their own ignorance requires them to contrast
> their ignorance with the knowledge that they are missing.
>
> Since they don't have this missing knowledge they cannot become directly
> aware that they are missing any knowledge. Their own ignorance is simply
> perceived as disagreement.

So, what actual FACT do you think I am missing?

I have stated specific rules that your 'claims' fail to follow. All you
have done is hurled insults. Who doesn't actually know what they are
talking about?

YOU are the one who has admitted to not having studied the theory, so
don't have a real basis to judge what they do not know.

You are the perfect example of Dunning-Kruger Effect. (Maybe you didn't
realize that the effect has an actual name because it has long been known).

One of your problems is that not having studied the history of the
field, you repeat the exact same errors that have been previously committed.

I will say you are somewhat inventive in how you try to express these
errors, but fundamentally many of them are ancient.

[olcott]

That the next level execution trace of the input to H(P,P) must be
identical to the first level trace.

[Richard Damon]

But you don't put difffernt levels of execution in a single trace.

THAT is the fact that I have pointed out and you refuse to comment on.

That make YOU statement illogical.

You confuse simulation with direct execution.

Yes, and UNCONDITIONAL simulation will give the same net results as a
direct exectution (when you take into account the indirection), but a
conditional simulation need not.

The "Sequence of states" that are passed through by the ACTUAL execution
hardware are different between a direct execution and a simulation, and
the trace needs to represent that difference.

You are just showing how little you understand about how computaters work.