Deutsch English Français Italiano |
<v38ogh$1grj4$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory,sci.logic Subject: Re: Two dozen people were simply wrong --- Try to prove otherwise Date: Wed, 29 May 2024 21:32:49 -0500 Organization: A noiseless patient Spider Lines: 152 Message-ID: <v38ogh$1grj4$1@dont-email.me> References: <v3501h$lpnh$1@dont-email.me> <v362eu$2d367$3@i2pn2.org> <v363js$vg63$2@dont-email.me> <v36803$2d368$3@i2pn2.org> <v368je$100kd$3@dont-email.me> <v373mr$2d367$5@i2pn2.org> <v37bpa$15n0b$1@dont-email.me> <v37i9p$lls$1@news.muc.de> <87y17smqnq.fsf@bsb.me.uk> <v37sap$18mfo$1@dont-email.me> <v38eq4$2foi0$1@i2pn2.org> <v38fe0$1bndb$1@dont-email.me> <v38g31$2foi0$11@i2pn2.org> <v38gi5$1bndb$3@dont-email.me> <v38ici$2fohv$2@i2pn2.org> <v38j17$1c8ir$2@dont-email.me> <v38jgo$2foi0$14@i2pn2.org> <v38jv9$1c8ir$4@dont-email.me> <v38kh7$2foi0$15@i2pn2.org> <v38lsl$1ggjs$1@dont-email.me> <v38o71$2foi0$17@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 30 May 2024 04:32:50 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0a722b73a14c6c7bef786c05822a9348"; logging-data="1601124"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195koUdX65OXp1PH/NRwi6s" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:0e15ehSeKv0r8k2eR1+Mnsj9vEo= Content-Language: en-US In-Reply-To: <v38o71$2foi0$17@i2pn2.org> Bytes: 7919 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 <acm@muc.de> 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 <is> 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). > A complete representation of the Turing Machine is NOT a level of > Indirection. > > Using a "Name" to represent that full description, THAT would be > indirection. > > The x86 code for your functions isn't a level of indirection from the > function itself. > > A word with the address of the function would be. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer