Re: Proof that DD correctly simulated by HH provides the correct halt status criteria

On 6/8/24 8:23 AM, olcott wrote:

On 6/8/2024 3:46 AM, Fred. Zwarts wrote:

Op 07.jun.2024 om 23:48 schreef olcott:

*That no counter-example to the following exists proves that it is true*
*That no counter-example to the following exists proves that it is true*
*That no counter-example to the following exists proves that it is true*
>
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
>
_DD()
[00001e12] 55         push ebp
[00001e13] 8bec       mov  ebp,esp
[00001e15] 51         push ecx
[00001e16] 8b4508     mov  eax,[ebp+08]
[00001e19] 50         push eax      ; push DD
[00001e1a] 8b4d08     mov  ecx,[ebp+08]
[00001e1d] 51         push ecx      ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
>
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
>
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
>
Halt deciders are required to compute the mapping from their
input to their own accept or reject state based on the behavior
that this input specifies.
>
Simulating halt deciders are not allowed to simulate non-halting
inputs for more than a finite number of steps because all deciders
must halt.
>
The basic strategy of a simulating halt decider is to simulate
an input until (a) The input halts or (b) it correctly determines
that the correctly simulated input cannot possibly stop running
unless its simulation has been aborted.
>
<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>
>
*Professor Sipser is the best selling author of this textbook*
Introduction to the Theory of Computation, by Michael Sipser
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years)
>
Subject: [Would the simulation of D be infinitely nested unless simulating partial halt decider H terminated its simulation of D?]
On 5/29/2021 2:26 PM, olcott wrote:
Message-ID: <YJKdnZg9v__rCC_9nZ2dnUU7-QXNnZ2d@giganews.com>
http://al.howardknight.net/?STYPE=msgid&MSGI=%3CYJKdnZg9v__rCC_9nZ2dnUU7-QXNnZ2d%40giganews.com%3E
>
The fact that the execution trace of D derived by the executed
H and the simulated H exactly matches the machine code of D
proves that each instruction of D was simulated correctly and
in the correct order this conclusively proves that D is correctly
simulated by both of these instances of H.
>
I explained these details hundreds of times in the last three
years and no one paid any attention to the fact that I proved
that I am correct. Because of this I provided the above dumbed
down version.
>

>
Olcott proved on 0.5.jun.2024 at 15:59 (CET) in very much detail that in the following example:
>
        typedef int (*ptr)();  // ptr is pointer to int function in C
>
        int H(ptr p, ptr i);
>
        int main()
        {
          return H(main, 0);
        }
>
his H, when used as a decider for the halting of main, produces a false negative. His own conclusion was that main halts, but that H reports non-halting.
>
So, the way out for him is that his H does not report about the reality (direct execution) but about H's decision procedure (the simulation).
So the report of H is no longer
a) main does not halt,
but
b) H decides that main does not halt.
>
The latter, of course, can be true even if the former is false.
We see this shift of the halting definition above, where he says that H is not deciding on the direct execution.
>
Of course, such reports are very uninteresting. The interest is for the halting of the direct execution. Almost nobody is interested in whether olcott's decider's simulation halts.

 I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
 (c) I provide this complete function

So?

 void DDD(int (*x)())
{
   HH(x, x);
}
 _DDD()
[00001de2] 55         push ebp
[00001de3] 8bec       mov ebp,esp
[00001de5] 8b4508     mov eax,[ebp+08]
[00001de8] 50         push eax         ; push DD
[00001de9] 8b4d08     mov ecx,[ebp+08]
[00001dec] 51         push ecx         ; push DD
[00001ded] e890f5ffff call 00001382    ; call HH
[00001df2] 83c408     add esp,+08
[00001df5] 5d         pop ebp
[00001df6] c3         ret
Size in bytes:(0021) [00001df6]
 Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.

Which just proves you don't understand what a proof is.
A proof will state the connection, not just claim a result.

 To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
 

Which means you just proved that NO HH that meets your requirements can ever give an answer for this question.
You Claim this not to be true, so that just shows that your system is self-contradictory.
And the apparent issue is that you are changing your definition of "Correct Simulation" between the two.
Apparently quite intentionally, so it can be considered an act of deception, commonly called a LIE.