Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis

On 6/8/2024 8:46 AM, joes wrote:

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

On 6/8/2024 1:42 AM, Mikko wrote:

On 2024-06-07 22:26:05 +0000, olcott said:

On 6/7/2024 4:00 PM, joes wrote:

Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:

On 6/7/2024 1:30 AM, Mikko wrote:

On 2024-06-06 15:31:36 +0000, olcott said:

On 6/6/2024 10:14 AM, Mikko wrote:

On 2024-06-06 13:53:58 +0000, olcott said:

On 6/6/2024 5:15 AM, Mikko wrote:

On 2024-06-05 13:29:28 +0000, olcott said:

On 6/5/2024 2:37 AM, Mikko wrote:

On 2024-06-04 18:02:03 +0000, olcott said:

 

Any finite string can be an input to some Turing machine.
Can you prove that a Turing machine is not a finite string?

By definition Turing Machines are not finite strings in the conventional
model. In my x86utm model of computation x86 machine language <is> the
input to another function written in the x86 language.

In your model, the machine code is also finite.
 

*That is correct so I rewrote my proof to fully account for that*
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
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.
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.

Your own attempts of a conter-proof are not about Turing machines but C

The C code forms an isomorphism to the peter Linz Turing machine
proof that cannot even be understood to be an isomorphism until
after the x86utm code is 100% fully understood.

programs. C programs are finite strings, so a C program is a valid
input to a C program (and a Turing machine, too).

They are about Turing Machines yet cannot be sufficiently understood
with less than the 100% compete precision of the x86 language. They
x86utm model is required to prove that false assumptions about the
nature of correct simulation are false assumptions.

You can't hide behind an x86 implementation. The same arguments hold.
Which assumptions are false?
 

I have all of the details of the machine code and C code for HH and DDD.
I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn
by analogy.

Why can't you do that? The simulator can simulate itself.
 

This means that H is not allowed to report on the behavior of the
directly executed P(P).

So on which program does it report then?

DD(DD) is just like infinite recursion that gets terminated at its
second recursive call. DD(DD) halts only because HH(DD,DD)
correctly determines that its input DOES NOT HALT.
If HH(DD,DD) did not correctly determine that its input DOES NOT HALT
then DD(DD) would never halt.

That doesn't make sense. The function halts because a simulator says it
doesn't?
 

It is a verified iff (if and only if) you have the required
prerequisite knowledge of (a) and (b) and carefully study
what the possible execution traces are for DDD correctly
simulated by any x86 emulator HH.
Saying that I am wrong without this mandatory prerequisite
knowledge or saying that I am wrong without carefully studying
my proof <is> defamation: a reckless disregard for the truth.
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
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.
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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer