Re: 195 page execution trace of DDD correctly simulated by HH0

On 6/20/24 10:12 AM, olcott wrote:

On 6/20/2024 3:09 AM, Fred. Zwarts wrote:

Op 20.jun.2024 om 02:00 schreef olcott:

This shows all of the steps of HH0 simulating DDD
calling a simulated HH0 simulating DDD
>
https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
*Some of the key instructions are color coded*
GREEN---DebugStep Address
RED-----HH Address
YELLOW--All of the DDD instructions
CYAN----Return from DebugStep to Decide_Halting_HH
>
_DDD()
[000020a2] 55         push ebp      ; housekeeping
[000020a3] 8bec       mov ebp,esp   ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404     add esp,+04   ; housekeeping
[000020b2] 5d         pop ebp       ; housekeeping
[000020b3] c3         ret           ; never gets here
Size in bytes:(0018) [000020b3]
>
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
>
>
>

>
If the simulation of a program with a loop of 5 iterations is aborted after 3 iterations, all instructions are correctly simulated. Nevertheless, it is an incorrect simulation, because it should simulate up to the final state of the program.
>

 It would be helpful if you answer the actual question being asked
right here and thus not answer some other question that was asked
somewhere else.

Why, you aren't?
You seem to think you are God or something that gets to set the rules.
YOU ARE NOT.

 

Similarly, if a simulator which aborts after 2 cycles of recursive simulation of it self, it simulates only 1 of the 2 cycles of itself. So, it is incorrect, not because one instruction was simulated incorrectly, but because it did not simulate up to the final state of the simulated self.
>

 void Infinite_Loop()
{
   HERE: goto HERE;
}
 It also looks like you fail to comprehend that it is possible
for a simulating termination analyzer to recognize inputs that
would never terminate by recognizing the repeating state of
these inputs after a finite number of steps of correct simulation.

Right, but they don't do it by "Correctly Simulating" the input, but by a PARTIAL simulation that provides the needed information to prove that an ACTUAL CORRECT (and complete) simulation of that input would not halt.
Not your incorrect indication that some OTHER input would not halt.

 

In other words, H0 is required to halt. If it does halt indeed, than a correct simulation can show the 'ret' instruction.

 If you look at the 195 page execution trace you will see that
the directly executed H0 does reach its ret instruction and
DDD correctly emulated by H0 cannot possibly reach its ret
instruction in any finite number of steps.

You mean the one that isn't the trace of the simulation of H0(DDD)?

 

We know that your simulation cannot do that. Your own words explain why it can't: the simulated self runs one cycle behind the simulator. That explains why the simulation is incorrect and aborts too soon.
>

 Every expert in the C language that has reviewed this in the C forums
and by personal email has confirmed that H0 must abort its simulation
of DDD to prevent its own non-termination. This seems to confirm your
lack of sufficient technical competence.

So? That isn't the question. THe question is once you have defined your H0, will the input built by the template on THAT H0 halt or not.
Your problem is you put the cart before the horse, and forget about the horse.

 

So, when you ask which step was emulated incorrectly, you only show that you don't understand what emulation is.
Stop talking about it. It is over your head.
>
I am afraid that these simple facts are over your head. I wonder what your reaction will be:
Shouting, complaining about change of subject, claiming that I do not understand it, or again a baseless repetition of the claim?
Whatever, it is not probable that it will show any insight in this matter with a reasonable response.