Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory,sci.logic Subject: Re: Olcott was simply wrong --- Try to prove otherwise Date: Thu, 30 May 2024 21:37:25 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: <87y17smqnq.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 31 May 2024 01:37:25 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2709506"; 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: 13815 Lines: 289 On 5/30/24 10:04 AM, olcott wrote: > On 5/30/2024 6:30 AM, Richard Damon wrote: >> On 5/29/24 11:58 PM, olcott wrote: >>> On 5/29/2024 9:55 PM, Richard Damon wrote: >>>> On 5/29/24 10:32 PM, olcott wrote: >>>>> On 5/29/2024 9:27 PM, Richard Damon wrote: >>>>>> On 5/29/24 9:48 PM, olcott wrote: >>>>>>> On 5/29/2024 8:24 PM, Richard Damon wrote: >>>>>>>> On 5/29/24 9:15 PM, olcott wrote: >>>>>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote: >>>>>>>>>> On 5/29/24 8:59 PM, olcott wrote: >>>>>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote: >>>>>>>>>>>> On 5/29/24 8:17 PM, olcott wrote: >>>>>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote: >>>>>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote: >>>>>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote: >>>>>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote: >>>>>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>> Alan Mackenzie writes: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> How about a bit of respect?  Mike specifically asked >>>>>>>>>>>>>>>>>>> you not to cite his >>>>>>>>>>>>>>>>>>> name as a back up for your points.  Why do you keep >>>>>>>>>>>>>>>>>>> doing it? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> He does it to try to rope more people in.  It's the >>>>>>>>>>>>>>>>>> same ploy as >>>>>>>>>>>>>>>>>> insulting people by name.  It's hard to ignore being >>>>>>>>>>>>>>>>>> maligned in public >>>>>>>>>>>>>>>>>> by a fool. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Thanks for validating my simplified encoding of the Linz* >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I really did believe that Ben Bacarisse was lying when >>>>>>>>>>>>>>>>> I said it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> At the time I was talking about the easily verified >>>>>>>>>>>>>>>>> fact of the actual >>>>>>>>>>>>>>>>> execution trace of fully operational code and everyone >>>>>>>>>>>>>>>>> was denying the >>>>>>>>>>>>>>>>> easily verified facts. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> typedef int (*ptr)();  // ptr is pointer to int >>>>>>>>>>>>>>>>> function in C >>>>>>>>>>>>>>>>> 00       int H(ptr p, ptr i); >>>>>>>>>>>>>>>>> 01       int D(ptr p) >>>>>>>>>>>>>>>>> 02       { >>>>>>>>>>>>>>>>> 03         int Halt_Status = H(p, p); >>>>>>>>>>>>>>>>> 04         if (Halt_Status) >>>>>>>>>>>>>>>>> 05           HERE: goto HERE; >>>>>>>>>>>>>>>>> 06         return Halt_Status; >>>>>>>>>>>>>>>>> 07       } >>>>>>>>>>>>>>>>> 08 >>>>>>>>>>>>>>>>> 09       int main() >>>>>>>>>>>>>>>>> 10       { >>>>>>>>>>>>>>>>> 11         H(D,D); >>>>>>>>>>>>>>>>> 12         return 0; >>>>>>>>>>>>>>>>> 13       } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It turns out that two dozen people are easily proven >>>>>>>>>>>>>>>>> wrong when >>>>>>>>>>>>>>>>> they claimed that the correct simulation of the input >>>>>>>>>>>>>>>>> to H(D,D) >>>>>>>>>>>>>>>>> is the behavior of int main() { D(D); } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> How is that? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> When D is correctly simulated by H using an x86 >>>>>>>>>>>>>>>>> emulator the only >>>>>>>>>>>>>>>>> way that the emulated D can reach its own emulated >>>>>>>>>>>>>>>>> final state >>>>>>>>>>>>>>>>> at line 06 and halt is >>>>>>>>>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly >>>>>>>>>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong >>>>>>>>>>>>>>>>> order >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition >>>>>>>>>>>>>>>> that allow the relating of a "Simulation" to the >>>>>>>>>>>>>>>> behavior of an input. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Right the execution trace of D simulated by pure function >>>>>>>>>>>>>>> H using >>>>>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach >>>>>>>>>>>>>>> its own >>>>>>>>>>>>>>> simulated final state and halt or the simulation of the >>>>>>>>>>>>>>> machine >>>>>>>>>>>>>>> language of D is incorrect or in the wrong order. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, you aren't going to resolve the question but just keep >>>>>>>>>>>>>> up with your contradiction that H is simulating a template >>>>>>>>>>>>>> (that doesn't HAVE any instrucitons of H in it) but also >>>>>>>>>>>>>> DOES simulate those non-existance instructions by LYING >>>>>>>>>>>>>> about what it does and simulating a SPECIFIC instance that >>>>>>>>>>>>>> it LIES behaves just like DIFFERENT specific instatces. >>>>>>>>>>>>> >>>>>>>>>>>>> I will give you the benefit of the doubt and call that an >>>>>>>>>>>>> honest >>>>>>>>>>>>> misunderstanding. I have much more empathy for you now that >>>>>>>>>>>>> I found >>>>>>>>>>>>> that Linz really did say words that you could construe as >>>>>>>>>>>>> you did. >>>>>>>>>>>>> >>>>>>>>>>>>> The infinite set of every H/D pair specified by the template >>>>>>>>>>>>> where D is correctly simulated by pure simulator H or pure >>>>>>>>>>>>> function >>>>>>>>>>>>> H never has any D reach its own simulated final state and >>>>>>>>>>>>> halt. >>>>>>>>>>>> >>>>>>>>>>>> But the question ISN'T about the SIMULATED D, but about the >>>>>>>>>>>> behavior of the actual PROGRAM/MACHINE D >>>>>>>>>>>> >>>>>>>>>>>> This seems to be your blind spot. >>>>>>>>>>> >>>>>>>>>>> ∃H  ∈ Turing_Machines >>>>>>>>>>> ∀x  ∈ Turing_Machines_Descriptions >>>>>>>>>>> ∀y  ∈ Finite_Strings >>>>>>>>>>> such that H(x,y) = Halts(x,y) >>>>>>>>>>> >>>>>>>>>>> Not really the above formalization does not can cannot >>>>>>>>>>> specify Turing Machines as the input to any decider H. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Then what is x representing? >>>>>>>>> >>>>>>>>> x a finite string Turing machine description that >>>>>>>>> SPECIFIES behavior. The term: "representing" is inaccurate. >>>>>>>>> >>>>>>>> >>>>>>>> No, it specifies the machine, and thus, though that, the behavior. >>>>>>>> >>>>>>> >>>>>>> If we assume that a decider takes an actual Turing machine as its >>>>>>> input that is correct otherwise that is one level of indirection >>>>>>> away from what we are really looking at. >>>>>>> >>>>>>> The people have perpetuated this mistake for many decades never >>>>>>> actually made it not a mistake. >>>>>>> >>>>>> >>>>>> You need to define what you mean by "Indirection", because you >>>>>> aren't using it in the normal manner. >>>>>> >>>>> >>>>> I have conclusively proven that the behavior of the correct >>>>> simulation of the x86 code of D by pure function H has >>>>> different behavior than the direct execution of D(D). >>>> >>>> But the question isn't about the "Correcgt Simulation" and >>>> especially based on YOUR definition. So you haven't proven ANYTHING >>>> about the question except that you don't understand it and are just >>>> an ignorant pathological liar with a reckless disregard for the trutn. >>>> >>>> You are just showing that you have successfully brainwashed yourself >>>> into beleiving your own lies. >>>> >>> >>> typedef int (*ptr)();  // ptr is pointer to int function in C ========== REMAINDER OF ARTICLE TRUNCATED ==========