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: Fri, 31 May 2024 11:08:53 +0300 Organization: - Lines: 89 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 10:08:54 +0200 (CEST) Injection-Info: dont-email.me; posting-host="add4eb6e9b456b964993c963c59aa7fe"; logging-data="2267904"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19STP3AvrNlbtBKGyH72lmQ" User-Agent: Unison/2.2 Cancel-Lock: sha1:nlNil+0liDIieoY5mS1LEanYHuw= Bytes: 5457 On 2024-05-30 09:08:05 +0000, joes said: > Am Wed, 29 May 2024 21:32:49 -0500 schrieb olcott: >> 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? > >>>>>>>>>>>>>> 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? > >>>>>>>>>>>>> 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. > Or aborts prematurely. > >>>>>>>>>>> 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. > >>>>>>>>> But the question ISN'T about the SIMULATED D, but about the >>>>>>>>> behavior of the actual PROGRAM/MACHINE D > Which should be the same. >>>>>>>>> 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. > What’s the difference? > >>>>> 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). > Then H is not a correct simulator. Either that or the correct simulation of the x86 of D by pure function H does not exists. If you ensure that H is not a pure functin or that H never performs a correct simulation of D you can say whatever you want about the impossible simulation, for example that it is yellow. -- Mikko