Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: How Partial Simulations correctly determine non-halting ---Ben's
 10/2022 analysis
Date: Sat, 8 Jun 2024 10:31:59 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v41q0v$3cg3s$1@i2pn2.org>
References: <v3j20v$3gm10$2@dont-email.me>
 <J_CdnTaA96jxpcD7nZ2dnZfqnPudnZ2d@brightview.co.uk>
 <87h6eamkgf.fsf@bsb.me.uk> <v3kcdj$3stk9$1@dont-email.me>
 <v3l7uo$13cp$8@dont-email.me> <v3lcat$228t$3@dont-email.me>
 <v3mq9j$chc3$1@dont-email.me> <v3mrli$chc4$1@dont-email.me>
 <_gWdnbwuZPJP2sL7nZ2dnZfqn_GdnZ2d@brightview.co.uk>
 <v3nkqr$h7f9$3@dont-email.me> <v3p4ka$sk6h$1@dont-email.me>
 <v3pp7p$v133$8@dont-email.me> <v3s27e$1f9kd$1@dont-email.me>
 <v3sf1n$1gra7$11@dont-email.me> <v3sjo9$1ialb$1@dont-email.me>
 <v3skoo$1iedv$1@dont-email.me> <v3u9ej$1v7rn$1@dont-email.me>
 <v3v6i7$23l33$1@dont-email.me> <v3vse5$3ao52$5@i2pn2.org>
 <v401dt$287qb$8@dont-email.me> <v40ufq$2gjsq$1@dont-email.me>
 <v41kse$2jqdk$9@dont-email.me> <v41nav$3crhv$1@i2pn2.org>
 <v41o9b$2kanc$11@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 8 Jun 2024 14:31:59 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3555452"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v41o9b$2kanc$11@dont-email.me>
Bytes: 8705
Lines: 180

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
========== REMAINDER OF ARTICLE TRUNCATED ==========