Re: Why do people here insist on denying these verified facts?

On 6/22/24 11:46 PM, olcott wrote:

On 6/22/2024 7:26 PM, Richard Damon wrote:

On 6/22/24 8:09 PM, olcott wrote:

On 6/22/2024 7:07 PM, Richard Damon wrote:

On 6/22/24 7:57 PM, olcott wrote:

On 6/22/2024 3:01 PM, joes wrote:

Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:

On 6/22/2024 2:19 PM, Richard Damon wrote:

On 6/22/24 3:03 PM, olcott wrote:

On 6/22/2024 1:55 PM, Richard Damon wrote:

On 6/22/24 2:49 PM, olcott wrote:

On 6/22/2024 1:43 PM, Richard Damon wrote:

On 6/22/24 1:29 PM, olcott wrote:

On 6/22/2024 12:13 PM, Richard Damon wrote:

On 6/22/24 12:18 PM, olcott wrote:

>

The correct measure of the behavior of the actual input is DDD correctly
simulated by H0 according to the definition of the semantics of the x86
programming language.

The correct measure is the behaviour of DDD itself. Any old simulator can
do it, but H0 specifically can't.
>

>
H0 has libx86emu embedded within it.
Several decades of development effort went into that.

>
But does it use it right?
>
After all, part of your problem is that you try to change the quesiton, and the right answer to the wrong question can be the wrong answer for the right question.
>
Your inability to get the required trace out makes me think you aren't actually doing what you claim to be doing.

>
It has been correct and proven correct for more than three
years yet damned liars here still deny it.

>
Then you could show the trace.
>
But you can't, so you are just a LIAR.
>
One issue is that three years ago, your were not as insistant on the x86 simulation, which gave you a bit more room to argue about equivalences (which you could never actually establish). By x86, you HAVE to trace from the pathological program into the decider and then show the steps in the decider to try to show your claim.
>

 Anyone that understands this knows that the call to H0(DDD)
from DDD correctly simulated by H0 cannot possibly return.

And who cares about that.
All that shows is that H0 correctly simulating this input does determine the actual behavior of the input.
Its correct simulation by H0 might not return, but its complete and correct simulation, as does its direct running does.

 That you have lied about this for three years makes you
look ridiculously foolish and might get you condemned to Hell.

Nope, might get you there, or you might have already had you ticket punched.

 Those that lie about climate change destroying the planet
for a few extra bucks probably do deserve 1000 years in Hell.
I myself would forgive you, yet not them.

And I am not one of those, but it seems you like to use the same sort of logic, so you are supporting them.

 _DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]
 

The problem is that then the ability for the decider being simulated to decide to stop its own simulation becomes evident, so you can't show that it never will.
>

 It is only the freaking ordinary infinite recursion behavior pattern.
I don't believe that you are too stupid to understand this.
If not stupid then evil.
 

Nope. becasue there is a conditional operation in the loop, that which is in H0.
Your arguemnt is based on the LIE that H0 isn't responsible for correctly deciding on what H0 will do.