Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point?

On 6/8/2024 5:25 PM, Richard Damon wrote:

On 6/8/24 5:58 PM, olcott wrote:

On 6/8/2024 4:48 PM, Richard Damon wrote:

On 6/8/24 5:38 PM, olcott wrote:

On 6/8/2024 4:28 PM, Richard Damon wrote:

On 6/8/24 5:14 PM, olcott wrote:

On 6/8/2024 3:57 PM, Richard Damon wrote:

On 6/8/24 4:52 PM, olcott wrote:

On 6/8/2024 3:47 PM, Richard Damon wrote:

On 6/8/24 4:34 PM, olcott wrote:

On 6/8/2024 3:23 PM, Richard Damon wrote:

On 6/8/24 1:10 PM, olcott wrote:

On 6/8/2024 11:03 AM, Richard Damon wrote:

On 6/8/24 11:32 AM, olcott wrote:

On 6/8/2024 10:15 AM, Richard Damon wrote:

On 6/8/24 11:07 AM, olcott wrote:

On 6/8/2024 9:54 AM, Richard Damon wrote:

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

On 6/8/2024 9:10 AM, Richard Damon wrote:

>
I HAVE pointed out what is missing, ANY set of truth-perserving operations from the accepted facts (which will of course need to name the fact they are working from) to your conclusion.

>
The accepted facts are here
(a) The x86 language
(b) The notion of an x86 emulator
>
{The proof that No DDD correctly emulated by any x86
  emulator H can possibly reach its own [00001df6] instruction}

>
So, how do you show this claim?
>
Do you have a tracing of the full INFINITE SET of possible Hs?
>

>
Is the set of possible execution traces of DDD correctly
emulated by x86 emulator HH on the basis of the above
accepted facts.
>
Maybe you are just clueless about these technical details
are are trying to hide this with pure bluster.
>
_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]
>
You keep disagreeing with the fact that DDD correctly
emulated by x86 emulator HH only has one single correct
execution trace of repeating the fist seven lines until
out-of-memory error.
>

>
But that is an INCORRECT trace per your definition,
>
The call HH instruction MUST be simulated into HH because that IS the behavior of the x86 instruction.

>
Did I ever say that it is not?
For the above DDD correctly emulated by x86 emulator HH
the first seven instructions of DD keep repeating because
DDD keeps calling HH(DDD,DDD) to emulate itself again and
again until HH/DDD hits out-of-memory exception.

>
So the x86 emulation of the code must go into HH(DDD,DDD)
>

>
It is pretty stupid to assume otherwise when HH is
stipulated to be an x86 emulator.

>
Right, so why did you say otherwise?
>

>
I never said otherwise you simply "read" meanings that I didn't say.
this thread: [Should I quit Richard at this point?]
stands alone and should not be interpreted within the
context of anything else that I ever said.

>
So, we are NOT to use your previous statements for earlier posts?
>
You keep on changing you mind, and not being clear. That shows your deceitful nature.
>

I must increasing narrow the focus of attention to ever
get any closure on as many as one single point.
>
The one point now is that DD correctly simulated by HH
proves that HH is correct to reject DD as non-halting.

>
Which is incorrect, because you are using the wrong definition of correct simulation.
>

>
For three years every reviewer has essentially insisted that the
correct measure of the behavior of DD is DD incorrectly simulated
by HH. The behavior of the directly executed DD(DD) cannot possibly
be achieved by DD correctly simulated by HH as the x86 machine-code
of DD *conclusively proves BEYOND ALL POSSIBLE DOUBT*
>

Nope, and if that is what your though, you are just an idiot.
>

>
When one disagrees with the execution trace that x86 code specifies
one is essentially doing the same thing as disagreeing with arithmetic.
>

>
And where does that say that the correct measure of the behavior of DD is DD incorrectly simulated?
>

>
I cut you off at your first big mistake so that we can focus
on correcting this big mistake.

>
And ignored the meaning of my statemert, and made you into a blantent LIAR.
>

>
*I can't address all of this point in one step because you*
*have proven that even one step is too confusing for you*
>
*I can't address all of this point in one step because you*
*have proven that even one step is too confusing for you*
>
*I can't address all of this point in one step because you*
*have proven that even one step is too confusing for you*
HERE IS STEP ONE
>
_DD()
[00001c22] 55         push ebp
[00001c23] 8bec       mov ebp,esp
[00001c25] 51         push ecx
[00001c26] 8b4508     mov eax,[ebp+08]
[00001c29] 50         push eax      ; push DD 1c22
[00001c2a] 8b4d08     mov ecx,[ebp+08]
[00001c2d] 51         push ecx      ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
>
*When DD is correctly simulated by simulating halt decider HH*
>
New slave_stack at:10306d
Begin Local Halt Decider Simulation   Execution Trace Stored at:113075
  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[00001c22][00113061][00113065] 55         push ebp         ; begin DD
[00001c23][00113061][00113065] 8bec       mov ebp,esp
[00001c25][0011305d][00103031] 51         push ecx
[00001c26][0011305d][00103031] 8b4508     mov eax,[ebp+08]
[00001c29][00113059][00001c22] 50         push eax         ; push DD
[00001c2a][00113059][00001c22] 8b4d08     mov ecx,[ebp+08]
[00001c2d][00113055][00001c22] 51         push ecx         ; push DD
[00001c2e][00113051][00001c33] e80ff7ffff call 00001342    ; call HH
New slave_stack at:14da95

>
ERROR!!! ERROR!! SIMULATION INCORECT
>
CALL 00001342 MUST be followed by the code at 00001342!!!!
>
Per the definition of correct simulation, needing to be in the order of the actual instructions executed.
>

>
*Stopping at first big mistake*
I simply do not display the extra 250 pages.
HH does correctly simulate itself simulating DD.
Have we gotten through the first 10% of STEP ONE?
>

>
Except that the simulation BY HH is not 250 pages.
>
That 250 pages is the trace of the direct execution of HH called by main.
>

>
I never bothered to notice this before yet that point is moot.
It is a verified fact that HH does simulate itself simulating DD.
>

 So, you obviously didn't look at it closely, so NOTHING has been verified in it.
 

When you know that an output is useless no sense making sure it
is correct. Yes it does show every detail of all of the code that
is directly executed and none of the derails of any simulated
code besides DD simulated by some HH.

It is too much work to extract the simulation HH did out of that listing, so I won't go to the effort to do that, and clearly YOU have done that work, so it si NOT verified that HH actually simulated itself.
 

Yes.

Especially, since your other traces, that you claim to be "correct" don't show it.
 So, until you fix that, it must be considered an UNVERIFIED claim.
 

No I just proved it another way.

And evidence that you often speak of things your haven't actually verified.
 

There is no way that the simulated HH can correctly output
its execution trace of DD if HH is not simulated.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer