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:37:13 -0500 Organization: A noiseless patient Spider Lines: 121 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:37:14 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0a722b73a14c6c7bef786c05822a9348"; logging-data="1586762"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+vxw6kwKHnOFKXATEn6wJo" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:sf3R2OI3kYgjNHlpAOiyhHO59Us= Content-Language: en-US In-Reply-To: Bytes: 6633 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. > That never has been the way that it has ever actually worked. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer