Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory,sci.logic Subject: Re: Two dozen people were simply wrong --- Try to prove otherwise Date: Wed, 29 May 2024 20:15:21 -0500 Organization: A noiseless patient Spider Lines: 114 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: Thu, 30 May 2024 03:15:22 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0a722b73a14c6c7bef786c05822a9348"; logging-data="1450587"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18gsk+GHxUVfHzdRxKCVCnR" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:OwXtZtkXGYxz/40c+9iim3zXuUw= In-Reply-To: Content-Language: en-US Bytes: 6128 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. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer