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

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.
What HH must decide on is the behavior of the direct exection of DD(DD) or the actual correct simulation of the representation of DD(DD) given to HH by a real UTM that keeps on simulating until it reaches a final state.
The fact that it is impossible for HH to do such a simulation, or even predict that simulation doesn't matter, that *IS* the criteria that it is responsible for.
The fact that it can't be done, just shows that Halting is not Computable, which is a perfectly fine results. There are a LOT of non-computable functions, in fact most Functions, if created at "random" would be not computable, since there are Aleph_1 Functions definable, but only Aleph_0 Computable functions,
Perhaps the surprising fact is that so many of the functions we might want turn out to be computable.
Somehow, something being impossible is beyond your mind power, and that is largly because your imagination of what can be done is too small, because you logic is too small. In "small" logic, you can't get the complexity that makes things impossible. But there is a border, that once you achieve that capability, your logic system can create problems that it can not solve.
This roughly comes up when the system tries to handle "infinite" things, as infinity creates some strange properties that give the system powers that it can't "control".