Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott 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:38:41 -0500 Organization: A noiseless patient Spider Lines: 178 Message-ID: References: <_gWdnbwuZPJP2sL7nZ2dnZfqn_GdnZ2d@brightview.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 08 Jun 2024 23:38:42 +0200 (CEST) Injection-Info: dont-email.me; posting-host="99ea1b6838dd1404bad406fc122dbf0f"; logging-data="2990088"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19dFygjqIWcgkNBc6aT4VG1" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:Owh0CYh9hRiQfdHIpo3sNHVJJig= In-Reply-To: Content-Language: en-US Bytes: 9953 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 >> [00001c2e][00113051][00001c33] e80ff7ffff call 00001342    ; call HH >> New slave_stack at:14da95 > > ERROR!!! ERROR!! SIMULATION INCORECT ========== REMAINDER OF ARTICLE TRUNCATED ==========