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

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

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.

Which isn't a proof, but a cla

 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.

No, a correct x86 emulator will follow the call HH into HH.
Now you are mixing H and HH was that intentional?
Remever the input is supposed to be calling the decider that you are going to claim is correct, have you gone farther down your stram man path?

 

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.

Nope.
The problem is that the Linz Turing Machines have H and H^ as two totally independent machines.
Your C code is ONE Program interacting with itself.
A correct equivalent should have H take a description of the input that it loads into a isolated virtual memory space that can't reference anything outside it, and then H simulates that program in that virtual memory space.

 

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.

Nope. No one has "verified it"

 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.

Which isn't a "Proof" but a claim.
To prove this, you need to state the sequence of truth-perserving operations that take you from your "facts" above to that claim.

 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.
 

Nope, it can't becuase the correct 86 emulation of DDD must go into the instructions of HH and will NEVER return to the begining of DDD again, only the simulation of those instructions. That is the actual behavior the x86 instructions presented simulated in the order presented to the simulator. The fact you haven't shown the code for HH either says we can't actually DO the simulation, or to do so, we first pair the DDD with a specific HH that simulates it, and every HH is doing a different simulation.
And, it seems your HH has lost its definition of being the decider that D was supposed to be refuting, so it seems you have gone farther down the straw man path.