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,sci.logic
Subject: Re: How Partial Simulations correctly determine non-halting ---Should
 I quit Richard at this point?
Date: Sat, 8 Jun 2024 16:23:21 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v42ejp$3cg3t$27@i2pn2.org>
References: <v3j20v$3gm10$2@dont-email.me> <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> <v3ve38$259cg$1@dont-email.me>
 <v3vf0b$24orn$4@dont-email.me> <v40u4u$2gi7t$1@dont-email.me>
 <v41k6l$2jqdk$8@dont-email.me> <v41l89$3cg3t$12@i2pn2.org>
 <v41nei$2kanc$8@dont-email.me> <v41oo8$3cg3t$22@i2pn2.org>
 <v41pbc$2kanc$15@dont-email.me> <v41raj$3cg3t$25@i2pn2.org>
 <v41s4e$2l7o9$2@dont-email.me> <v41sjf$3cg3s$8@i2pn2.org>
 <v41tj5$2ll6e$1@dont-email.me> <v41vc6$3cg3t$26@i2pn2.org>
 <v423a9$2m6lc$1@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 20:23:22 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3555453"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v423a9$2m6lc$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 21632
Lines: 548

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.

Note, your TOPIC still indicates we are talking about Halting.

You should not be reusing names for very different things.

If HH is just a simulator, it should be called

In that case, why do we care about any of this, if D isn't supposed to 
be the D of the proofs, why do we care at all about it?

My guess is you are just losing your mental facilities and are 
forgetting what you are trying to do.

> 
>>>
>>>> The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get 
>>>> to the sequence of instrucitions starting at 00001DE2, as the code 
>>>> will never jump there to just execute it.
>>>>
>>>
>>> Your are saying that incorrectly DDD correctly emulated by
>>> x86 emulator HH cannot possibly reach it own machine address
>>> of [00001df6].
>>
>> I said nothing about that. You are just serving Herring with Red Sauce 
>> agian.
>>
> 
>  >>> The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get
>  >>> to the sequence of instructions starting at 00001DE2

WHO CARES.

Since you just admitted that DDD isn't at all related to the H^ of Linz 
or D or Sipser, and neither is HH the H of eaither, why should anyone care?

> 
> Wrong! DDD correctly simulated by HH will never reach its own
> machine address of 00001df6 because DDD correctly simulated
> by HH keeps starting over with another instance of itself at
> 00001DE2 after the prior instance calls HH(DDD,DDD) to simulate
> itself again.

No, it will NOT  "restart" as the code didn't reset.

You just don't seem to understand the meaning of your own defintion of 
correct simulation.

If HH is correctly simulating the x86 code it sees, then it simulates 
the code of DDD, then the code of HH simulating the code of DDD, then 
the code of HH now simulating the code of HH simulating the code of DDD

it NEVER gets back to simulating the code of DDD.

> 
>> The CORRECT simulation of DDD can NEVER get back to the sequence of 
>> instructions at 00001DE2, as there is never a jump to that address, 
>> only the emulator starting an emuation of that address, and the 
>> correst simulation of a simulatore is NOT the code the simulated 
>> simulator is looking at, but the code of the simulator doing the 
>> simulation.
>>
> 
> DDD correctly simulated by HH will never reach its own
> machine address of 00001df6 because DDD correctly simulated
> by HH keeps starting over with another instance of itself at
> 00001DE2 after the prior instance calls HH(DDD,DDD) to simulate
> itself again.

Nope, it appear to get stuck in HH simulating itself, simulating itself, ...

It NEVER gets back to DDD.



> 
>>>
>>>> By your code, the simulator will "Debug Step" those instructions.
>>>>
>>>
>>> The underlying details of one HH are irrelevant when I reference
========== REMAINDER OF ARTICLE TRUNCATED ==========