Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory Subject: Re: Two dozen people were simply wrong --- Try to prove otherwise Date: Thu, 30 May 2024 21:37:23 -0400 Organization: i2pn2 (i2pn.org) 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 01:37:23 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2709506"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird In-Reply-To: Content-Language: en-US X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 8530 Lines: 177 On 5/30/24 9:31 AM, olcott wrote: > On 5/30/2024 2:40 AM, Mikko wrote: >> 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. > > That is what I said. Note, the string doesn't DIRECTLY specify behavior, but only indirectly as a description/representation of the Turing Mach > >> 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. > > Yes that is also correct. > > When Ĥ is applied to ⟨Ĥ⟩ > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn > > When embedded_H is a UTM then it never halts. But it isn't unless H is also a UTM, and then H never returns. You like to keep returning to that deception. > > When embedded_H is a simulating halt decider then its correctly > simulated input never reaches its own simulated final state of > ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its > input as non-halting. Except that isn't what the question is, the question is what the actual behavior of the machine described, or equivalently, the simulation by a REAL UTM (one that never stops till done). As has been shown, H / embedded_H can't be that and answer, so either your embedded_H needs to answer about a simulation done by a different machine (which seems beyond your understanding) or you just don't have a valid criteria to use. > > >> 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. >> > ========== REMAINDER OF ARTICLE TRUNCATED ==========