Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon 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 17:48:10 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 8 Jun 2024 21:48:10 -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: X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US Bytes: 10580 Lines: 195 On 6/8/24 5:38 PM, olcott wrote: > On 6/8/2024 4:28 PM, Richard Damon wrote: >> On 6/8/24 5:14 PM, olcott wrote: >>> On 6/8/2024 3:57 PM, Richard Damon wrote: >>>> On 6/8/24 4:52 PM, olcott wrote: >>>>> On 6/8/2024 3:47 PM, Richard Damon wrote: >>>>>> 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. >>>>>> >>>>> >>>>> When one disagrees with the execution trace that x86 code specifies >>>>> one is essentially doing the same thing as disagreeing with >>>>> arithmetic. >>>>> >>>> >>>> And where does that say that the correct measure of the behavior of >>>> DD is DD incorrectly simulated? >>>> >>> >>> I cut you off at your first big mistake so that we can focus >>> on correcting this big mistake. >> >> And ignored the meaning of my statemert, and made you into a blantent >> LIAR. >> >>> >>> *I can't address all of this point in one step because you* >>> *have proven that even one step is too confusing for you* >>> >>> *I can't address all of this point in one step because you* >>> *have proven that even one step is too confusing for you* >>> >>> *I can't address all of this point in one step because you* >>> *have proven that even one step is too confusing for you* >>> HERE IS STEP ONE >>> >>> _DD() >>> [00001c22] 55         push ebp >>> [00001c23] 8bec       mov ebp,esp >>> [00001c25] 51         push ecx >>> [00001c26] 8b4508     mov eax,[ebp+08] >>> [00001c29] 50         push eax      ; push DD 1c22 >>> [00001c2a] 8b4d08     mov ecx,[ebp+08] >>> [00001c2d] 51         push ecx      ; push DD 1c22 >>> [00001c2e] e80ff7ffff call 00001342 ; call HH >>> >>> *When DD is correctly simulated by simulating halt decider HH* >>> >>> New slave_stack at:10306d >>> Begin Local Halt Decider Simulation   Execution Trace Stored at:113075 >>>   machine   stack     stack     machine    assembly >>>   address   address   data      code       language >>>   ========  ========  ========  =========  ============= >>> [00001c22][00113061][00113065] 55         push ebp         ; begin DD >>> [00001c23][00113061][00113065] 8bec       mov ebp,esp >>> [00001c25][0011305d][00103031] 51         push ecx >>> [00001c26][0011305d][00103031] 8b4508     mov eax,[ebp+08] >>> [00001c29][00113059][00001c22] 50         push eax         ; push DD >>> [00001c2a][00113059][00001c22] 8b4d08     mov ecx,[ebp+08] >>> [00001c2d][00113055][00001c22] 51         push ecx         ; push DD ========== REMAINDER OF ARTICLE TRUNCATED ==========