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

Am Mon, 10 Jun 2024 12:54:48 -0500 schrieb olcott:

On 6/10/2024 6:16 AM, Richard Damon wrote:

On 6/10/24 1:17 AM, olcott wrote:

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

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

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.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. 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.

Why does it need to abort, when its recursive simulation does the same
and thus returns, not needing to be aborted?

So, I guess you are admitting that this means that "D correctly
simulated by H" is NOT a possible equivalent statement for the behavior
of the direct execution of the input as required by the Halting
Problem,
so you admit you have been LYING every time you imply that it is.

Are you saying that the simulation can be different from the direct
execution?

The only way for D simulated by H to have the same behavior as the
directly executed D(D) is for D simulated by H to skip over this call.

Does D(D) skip over this call?

Your problem is that it turns out that the only way that a correct
simulation by H to be an actual correct simulation that shows halting
behavior, it can't answer and be a decider.

[no answer]

But your H DOES ignore the CORRECT behavior of that instruction, as a
correct simulation of that instruction (by what ever type of simulation
you want to do) must either continue it trace into the function H
(which none of your published traces of the results of the simulation H
does do) if the simulation instruction level, or it must show the
effective behavior of the actual function H, which is to return 0
(since you claim you H is correct, and correct to return 0).
Neither of these is what your "correct simulation" of the input does,
so it can not be a correct simulation of the input. Your H just doesn't
"correctly simulate" that call instruction, but does invalid logic to
conclude the wrong answer.
It seems impossible for you claim that you have looked at the trace of
H acually doing the x86 instruction trace of H to show that it was
correctly determining what you claim, as your "250 page" trace turns
out not to be that trace, and you admit you didn't look at it closely,
and you JUST think you figured out how to get such a trace out.
 

There is no need to look at the trace of H correctly simulated by H when
the trace of D correctly simulated by simulated H is proven to be
correct.

--
joes