Deutsch English Français Italiano |
<v33iqc$ebbg$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder8.news.weretis.net!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: =?UTF-8?Q?Re=3A_A_simulating_halt_decider_applied_to_the_The_Peter_?= =?UTF-8?Q?Linz_Turing_Machine_description_=E2=9F=A8=C4=A4=E2=9F=A9?= Date: Mon, 27 May 2024 22:24:59 -0500 Organization: A noiseless patient Spider Lines: 169 Message-ID: <v33iqc$ebbg$1@dont-email.me> References: <v2nsvh$1rd65$2@dont-email.me> <v2vg1g$3e8pb$4@dont-email.me> <v2vo5h$26570$3@i2pn2.org> <v2vpt6$3g0m3$3@dont-email.me> <v2vqou$26570$5@i2pn2.org> <v2vrcl$3gakv$1@dont-email.me> <v2vslp$26570$6@i2pn2.org> <v301m6$3hcgb$1@dont-email.me> <v305j9$26571$1@i2pn2.org> <v30e5l$3lerc$1@dont-email.me> <v30fbr$26570$9@i2pn2.org> <v30hiq$3lv80$1@dont-email.me> <v30jb5$26571$2@i2pn2.org> <v30pr8$3r67p$1@dont-email.me> <v30rvv$3riij$1@dont-email.me> <v30t8u$26571$6@i2pn2.org> <v30u04$3rour$1@dont-email.me> <v30upc$26571$7@i2pn2.org> <v30vp3$3s4od$1@dont-email.me> <v321o0$28n58$1@i2pn2.org> <v3255k$2pkb$2@dont-email.me> <v326fd$28n59$2@i2pn2.org> <v327h8$3a17$1@dont-email.me> <v328l1$28n58$2@i2pn2.org> <v329t8$3mh0$2@dont-email.me> <v32ait$28n58$4@i2pn2.org> <v32bvc$48pj$1@dont-email.me> <v32cko$2937i$1@i2pn2.org> <v32nsa$6fo3$1@dont-email.me> <v32tfs$29dee$1@i2pn2.org> <v331mf$84p2$1@dont-email.me> <v332ci$29def$2@i2pn2.org> <v33790$8u5p$1@dont-email.me> <v337r0$29dee$2@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 28 May 2024 05:25:00 +0200 (CEST) Injection-Info: dont-email.me; posting-host="62ab2bf33c274f123184493b42753dfc"; logging-data="470384"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Y3LbmFIzixhSwlKB5j1jG" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:9vuAbP62pUwxldvc+XUrB2hQfIY= In-Reply-To: <v337r0$29dee$2@i2pn2.org> Content-Language: en-US Bytes: 8869 On 5/27/2024 7:17 PM, Richard Damon wrote: > On 5/27/24 8:08 PM, olcott wrote: >> On 5/27/2024 5:44 PM, Richard Damon wrote: >>> On 5/27/24 6:32 PM, olcott wrote: >>>> On 5/27/2024 4:21 PM, Richard Damon wrote: >>>>> On 5/27/24 3:45 PM, olcott wrote: >>>>>> On 5/27/2024 11:33 AM, Richard Damon wrote: >>>>>>> On 5/27/24 12:22 PM, olcott wrote: >>>>>>>> On 5/27/2024 10:58 AM, Richard Damon wrote: >>>>>>>>> On 5/27/24 11:46 AM, olcott wrote: >>>>>>>>>> On 5/27/2024 10:25 AM, Richard Damon wrote: >>>>>>>>>>> On 5/27/24 11:06 AM, olcott wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 } >>>>>>>>>> >>>>>>>>>> The above template refers to an infinite set of H/D pairs >>>>>>>>>> where D is >>>>>>>>>> correctly simulated by either pure simulator H or pure >>>>>>>>>> function H. This >>>>>>>>>> was done because many reviewers used the shell game ploy to >>>>>>>>>> endlessly >>>>>>>>>> switch which H/D pair was being referred to. >>>>>>>>>> >>>>>>>>>> *Correct Simulation Defined* >>>>>>>>>> This is provided because many reviewers had a different >>>>>>>>>> notion of >>>>>>>>>> correct simulation that diverges from this notion. >>>>>>>>>> >>>>>>>>>> A simulator is an x86 emulator that correctly emulates 1 >>>>>>>>>> to N of the >>>>>>>>>> x86 instructions of D in the order specified by the x86 >>>>>>>>>> instructions >>>>>>>>>> of D. This may include M recursive emulations of H >>>>>>>>>> emulating itself >>>>>>>>>> emulating D. >>>>>>>>> >>>>>>>>> And how do you apply that to a TEMPLATE that doesn't define >>>>>>>>> what a call H means (as it could be any of the infinite set of >>>>>>>>> Hs that you can instantiate the template on)? >>>>>>>>> >>>>>>>> >>>>>>>> *Somehow we got off track of the subject of this thread* >>>>>>> >>>>>>> I note that YOU keep on switching between your C program and >>>>>>> Turing Machines. >>>>>>> >>>>>>> Note, per the implications that you implicitly agreed to (by not >>>>>>> even trying to refute) the two systems are NOT equivalents of >>>>>>> each other. >>>>>>> >>>>>> >>>>>> (1) I think you are wrong. I have not seen any of your >>>>>> reasoning that was not anchored in false assumptions. >>>>>> Your make fake rebuttal is to change the subject. >>>>>> >>>>>> (2) It does not matter my proof is anchored in the Linz >>>>>> proof and the H/D pairs are only used to have a 100% concrete >>>>>> basis to perfectly anchor things such as the correct meaning >>>>>> of D correctly simulated by H so that people cannot get away >>>>>> with claiming that an incorrect simulation is correct. >>>>>> >>>>>> int main() { D(D); } IS NOT THE BEHAVIOR OF D CORRECTLY SIMULATED >>>>>> BY H. >>>>>> One cannot simply ignore the pathological relationship between H >>>>>> and D. >>>>>> >>>>>>>> >>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>> >>>>>>>> Ĥ copies its own Turing machine description: ⟨Ĥ⟩ >>>>>>>> then invokes embedded_H that simulates ⟨Ĥ⟩ with ⟨Ĥ⟩ as input. >>>>>>>> >>>>>>>> For the purposes of the above analysis we hypothesize that >>>>>>>> embedded_H is either a UTM or a UTM that has been adapted >>>>>>>> to stop simulating after a finite number of steps of simulation. >>>>>>> >>>>>>> And what you do mean by that? >>>>>>> >>>>>>> Do you hypothesize that the original H was just a pure UTM, >>>>>> >>>>>> The original proof does not consider the notion of a simulating >>>>>> halt decider so I have to begin the proof at an earlier stage >>>>>> than any definition of H. >>>>> >>>>> The biggest problem is that the input to the Turing machine decider >>>>> H is the description of a Turing Machine H^, which is a SPECIFIC >>>>> machine, >>>> >>>> When you say "specific machine" you don't mean anything like a >>>> 100% completely specified sequence of state transitions encoded >>>> as a single unique finite string. >>> >>> Mostly. >>> >>> There doesn't need to be a unique finite string, but it is a 100% >>> completely specified state transition/tape operation table. >>> >> >> When Ĥ is applied to ⟨Ĥ⟩ >> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >> >> In other words Linz did not prove that there are no set >> of state transitions specified by ⊢* that derives the >> correct halt status of ⟨Ĥ⟩ ⟨Ĥ⟩. >> >> He only said there there is one specific machine that >> gets the wrong answer. >> > > He STARTS with a proof that one specific (but arbitrary) machine gets > the wrong answer. > *Not exactly, you are misreading this* The domain of this problem is to be taken as the set of all Turing machines and all w; that is, we are looking for a single Turing machine that, given the description of an arbitrary M and w, will predict whether or not the computation of M applied to w will halt. .... Proof: We assume the contrary, namely that there exists an algorithm, and consequently some Turing machine H, that solves the halting problem https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf Ordinary existential quantification looks for at least one element not exactly one element: Does at least one Turing machine exist of the infinite set of all Turing machines ... So like I have always said, the second ⊢* specifies an infinite set of Turing machines. When Ĥ is applied to ⟨Ĥ⟩ Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn > Then he shows that the same proof can be applied to ANY such machine > (becaue the proof didn't depend on any specific details of the machine, > just the general properties of that machine) > ========== REMAINDER OF ARTICLE TRUNCATED ==========