Re: Proof that DD correctly simulated by HH has different behavior than DD(DD) STEP(1)

On 6/9/24 8:21 AM, olcott wrote:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:
>
<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 words10/13/2022>
>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
 > I don't think that is the shell game. PO really /has/ an H
 > (it's trivial to do for this one case) that correctly determines
 > that P(P) *would* never stop running *unless* aborted.
>
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

>
Stopping at your first error. So, we can focus on it. Your are asking a question that contradicts itself.

 In other words the best selling author of theory of
computation textbooks doesn't have a clue?

Nope, you asked him a defective question, and he did his best.
H can not have done a correct simulation, per the definitions in place, and abort its simulation.

 

A correct simulation of HH that aborts itself,
should simulate up to the point where the simulated HH aborts.

 The outer HH always sees a longer execution trace than
the inner ones. Unless the outer one aborts none of them
abort.

No, you are forgetting that simulation is not the reality, but an exploration of it.
THe outer HH sees a longer execution trace then the simulated part of the inner one.
"The inner one" would generally mean the execution of that inner one, (not an aborted simualation of it) and that, since it is the exact same algorithm and data, will see EXACTLY the same execution trace as the outer one saw when it interrupt its simulation.
Your problem is you seem to have forgotten that simulation are just explorations of the reality of the execution, and not a reality of themselves.

 

That is logically impossible. So, either it is a correct simulation and then we see that the simulated HH aborts and returns, or the simulation is incorrect, because it assumes incorrectly that things that happen (abort) do not happen.
A premature conclusion.
>
>

 _DD()
[00001e32] 55               push ebp      ; Begin DD
[00001e33] 8bec             mov ebp,esp
[00001e35] 51               push ecx
[00001e36] 8b4508           mov eax,[ebp+08]
[00001e39] 50               push eax      ; push DD
[00001e3a] 8b4d08           mov ecx,[ebp+08]
[00001e3d] 51               push ecx      ; push DD
[00001e3e] e83ff5ffff       call 00001382 ; call DD
 If you can't see this then you seem to just not have
enough technical skill:
 The first seven steps of DD correctly simulated by HH call
HH(DD,DD) to repeat these first seven steps.

Nope, becase the outer simulator, if simulating per your definition, won't simulate the input given to that simulated HH, but will simulate the CODE of HH as it simulates DD(DD).
So that outer HH will NEVER see the actual address 00001E32 again. EVER.

 HH then simulates itself simulating DD until this second
instance of DD calls another HH(DD,DD) to repeat these first
seven steps again.
 

Which means you keep on changing what simulation you are looking at, which violates your definiton of simulation.