Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Mikko Newsgroups: comp.theory Subject: Re: Two dozen people were simply wrong --- Try to prove otherwise Date: Thu, 30 May 2024 10:40:02 +0300 Organization: - Lines: 119 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 09:40:03 +0200 (CEST) Injection-Info: dont-email.me; posting-host="171987d8304ab438b73528bfdb9cffdc"; logging-data="1690453"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18BZ41d6ergtxPhh2wX4zWW" User-Agent: Unison/2.2 Cancel-Lock: sha1:anDmticAfFvfifngFBTrdKWjxIE= Bytes: 6467 On 2024-05-30 01:15:21 +0000, olcott said: > 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, x is a description of the Turing machine that specifies the behaviour that H is required to report. The maning of x is that there is a universal Turing machine that, when given x and y, simulates what the described Turing machine does when given y. Therefore, you may reformulate the requirement: ∀x  ∈ Turing_Machines_Descriptions ∀y  ∈ Finite_Strings H(x,y) returns "yes" if UTM(x,y) halts and "no" otherwise. -- Mikko