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

On 6/9/24 12:02 AM, olcott wrote:

On 6/8/2024 10:53 PM, Richard Damon wrote:

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

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

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

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

On 6/8/24 6:04 PM, olcott wrote:

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

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

On 6/8/2024 4:37 PM, joes wrote:

Am Sat, 08 Jun 2024 15:15:45 -0500 schrieb olcott:

On 6/8/2024 2:59 PM, joes wrote:

Am Sat, 08 Jun 2024 13:36:04 -0500 schrieb olcott:

On 6/8/2024 1:12 PM, joes wrote:

Am Sat, 08 Jun 2024 12:10:33 -0500 schrieb olcott:

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:

>
What are all the other HH?

Still waiting on this.

>

A simulator that simulates something different than the real thing is
not a simulator.

DD *correctly* simulated by HH has provably different behavior than the
directly behavior of the executed DD(DD).

 >

I mean, if one of them must be wrong, it can only be the simulator.
>

>
I proved otherwise and you ignored it.
>
I am always going to stop reading at the first big mistake
so this mistake can be focused on an corrected.
>

>
So, you should have stopped reading your own writing decades ago.
>
When are you going to fix your x86utm to match your current definition of correct simulation?

>
The simulated of DD is proven to be correct by the fact
that both execution traces match the x86 source-code of DD.
>

>
Except that the actual x86 trace never gets back there, so this is NOT a "Correct simulation" trace of the input.
>

>
Yes and by this same incorrect reasoning
<sarcasm>
   we know that all infinite recursion always
   terminates normally because "infinite recursion" is a
   term-of-the-art that means {terminates normally}.
</sarcasm>
>

>
So, how does the x86 processor get back to executing that adderess in the direct simulation by the outer HH as required by your definition of correct simulation.
>

>
Are you asking how does infinite recursion terminate normally?

>
No, are you THAT stupid?
>

 I only missed Mensa by one point I am in the top 97%
I was also top in several of my computer science classes.

Then why ard you so ignorant of thing you claim to know something about?

 

I am asking how the x86 processor gets from calling HH(DD,DD) back to the begining of DD as code actually executed, so it shows up in the simulation of the HH that was simulating that DD.
>
When the HH that this DD calls starts it simulation, since you have stated this is done by pure emulation, when did the program counter for that thread of execution ever get set back to the begining of DD.
>
Note, NOT the "virtual program counter that the simulator being simulated was using in its simulation (since that isn't anywhere in your definition of correct simulation) but the actual Program Counter in the simulation being run get there?
>

 *See if this explains it*
 _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
 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.
 In other words the first seven steps of DD correctly simulated
by HH call HH(DD,DD) to repeat these first seven steps. HH then
simulates itself simulating DD until this second instance of DD
calls another HH(DD,DD) to repeat these first seven steps again.

But by the first paragraph, the exectution of the seventh instruction, leaves the program counter at 00001C2E, so by the rule of correctly simulated in the correct order, the only allowed instruction to simulate next is the call HH at 00001C2E.
EXPLAIN HOW THAT IS NOT RIGHT, Reference the document which shows your idea is an actual correct simulation of the x86 instruction.
Then when we simulate the CALL 00001342 instruction, that leaves the program counter at 00001362, o by te rules of correctly simulated in the correct order, the only alloed instruction to simulate next is the instruction at 00001362.
Again, EXPLAIN HOW THAT IS NOT RIGHT, Reference the document which shows your idea is an actual correct simulation of the x86 instruction.
That is the EXACT behavior specified by those instructions, so ANY other behavior is NOT a "correct simulaition of the instruction" and going to any other instruction other than the one the Program Counter current points to is not in the correct order.
Until you answer, any other remarks will get answered by the fact that you have been caught in a falsehood, and are trying to do a dishonest dodge to get out of handling it.

 

>

Since you have admitted to falsifing your verification, you are going to have to actual show your information.
>

>
*I have proved this point since three years ago*
On 5/29/2021 2:26 PM, olcott wrote:
[Would the simulation of D be infinitely nested unless simulating partial halt decider H terminated its simulation of D?]
Message-ID: <YJKdnZg9v__rCC_9nZ2dnUU7-QXNnZ2d@giganews.com>
>

>
Not the quesiton being asked, which is par for the course with you.
>
Remember, you just admitted to claiming verification with an output you didn't actually look at closely, so nothing "verified" by you can be considered verified.
>
You have burnt that bridge, you are going to need to provide the "paperwork" for the things you claim to be verified.
>
We can get to that question later, once we get your simulations to actually meet your specifications, which they currently do not.
>
Seems strange that a programmer with the qualifications you have claimed would have missed such an obvious error, I guess you just never check your work.
>