Deutsch English Français Italiano |
<v3l3rm$tom$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 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_--_key_d?= =?UTF-8?Q?etails?= Date: Mon, 3 Jun 2024 14:00:04 -0500 Organization: A noiseless patient Spider Lines: 208 Message-ID: <v3l3rm$tom$1@dont-email.me> References: <v2nsvh$1rd65$2@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> <v338c5$94g8$1@dont-email.me> <v339kr$29dee$3@i2pn2.org> <v33aj7$9f3u$1@dont-email.me> <v33bo5$29def$4@i2pn2.org> <v33dt7$dlnv$1@dont-email.me> <v33f6d$29dee$4@i2pn2.org> <v33g9j$e3ug$1@dont-email.me> <v33gss$29def$6@i2pn2.org> <v33hbf$e6qn$1@dont-email.me> <v34fg0$2bb65$2@i2pn2.org> <v36pgt$12lh7$1@dont-email.me> <v379la$159q4$2@dont-email.me> <v398hu$1j7to$1@dont-email.me> <v39ue9$1mtd9$3@dont-email.me> <v3chls$280e0$1@dont-email.me> <v3cqnm$29gdk$1@dont-email.me> <v3ek0l$2maau$1@dont-email.me> <v3fbme$2qsgd$1@dont-email.me> <v3fqkp$2o13h$7@i2pn2.org> <v3fsm0$2uah1$1@dont-email.me> <v3h7pv$38up4$1@dont-email.me> <v3hrlk$3bkv5$3@dont-email.me> <v3jt7u$3qf1g$1@dont-email.me> <v3kdbg$3stk9$4@dont-email.me> <v3kmo4$3umuf$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 03 Jun 2024 21:00:07 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f629d257ac302b24ac32e99a4ff4b1b3"; logging-data="30486"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19137isA/cmYZ2jhmDXDQu9" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:0CV1NXMYPd9VHgVFalSvtVMGhGQ= Content-Language: en-US In-Reply-To: <v3kmo4$3umuf$1@dont-email.me> Bytes: 10474 On 6/3/2024 10:16 AM, Mikko wrote: > On 2024-06-03 12:36:00 +0000, olcott said: > >> On 6/3/2024 3:01 AM, Mikko wrote: >>> On 2024-06-02 13:21:56 +0000, olcott said: >>> >>>> On 6/2/2024 2:42 AM, Mikko wrote: >>>>> On 2024-06-01 19:26:55 +0000, olcott said: >>>>> >>>>>> On 6/1/2024 1:52 PM, joes wrote: >>>>>>> Am Sat, 01 Jun 2024 09:37:01 -0500 schrieb olcott: >>>>>>>> On 6/1/2024 2:52 AM, Mikko wrote: >>>>>>>>> On 2024-05-31 15:35:18 +0000, olcott said: >>>>>>> >>>>>>>>>> *A quick summary of the reasoning provided below* >>>>>>>>>> The LHS is behavior that embedded_H is allowed to report on. >>>>>>>>> There is no restrictions on what embedded_H is allowed to >>>>>>>>> report on. >>>>>>>> >>>>>>>> embedded_H is only allowed to report on the behavior that its >>>>>>>> finite >>>>>>>> string Turing Machine Description specifies to a UTM. >>>>>>>> >>>>>>>> embedded_H <is> a UTM except that it stops simulating and reports >>>>>>>> non-halting as soon as it correctly recognizes a non-halting >>>>>>>> behavior >>>>>>>> pattern that is specified by its input. >>>>>>> "Except". So it is not an UTM. >>>>>>> >>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>> >>>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩ >>>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩ >>>>>>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>> (g) goto (d) >>>>>>>> >>>>>>>> embedded_H is not allowed to be applied to Ĥ ⟨Ĥ⟩ because inputs can >>>>>>>> only be finite strings and Ĥ is not a finite string. This means >>>>>>>> that embedded_H is not allowed to report on its own actual >>>>>>>> behavior. >>>>>>> I can't read that notation. What is H^ and what does it look like? >>>>>>> >>>>>> >>>>>> *Here is the whole Linz proof* >>>>>> I simplified the Linz notation at the bottom of page 2 of the proof. >>>>>> https://www.liarparadox.org/Linz_Proof.pdf >>>>> >>>>> You are right, that is a sufficient proof. You may change the >>>>> presentation >>>>> but then you must prove that your presentation is equivalent to Linz'. >>>> >>>> The proof was removed until Joe could understand what Linz was saying >>>> Here is my actual proof. >>> >>> Linz' proof is Linz' proof, not yours. >>> >>>> When Ĥ is applied to ⟨Ĥ⟩ >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>> >>> The above does not say what Linz said and hardly anything else, either. >>> It is not a sentence. If you remove the second last or the last line >>> or add some conjunction between them and add a point to the end then >>> you would have a sentence. >>> >>>> (a) Ĥ copies its input ⟨Ĥ⟩ >>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ >>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩ >>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ >>>> (g) goto (d) >>>> >>>> Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ derives a different result than >>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩. >>> >>> Irrelevant as embedded_H is not a part of Linz' proof. The part >>> of Linz' Ĥ that corresponds to your embedded_H does produce the >>> same result as Linz H does. >>> >> >> https://www.liarparadox.org/Linz_Proof.pdf top of page 3 >> Linz named his embedded_H "Ĥq0" and has input Wm Wm >> because this is a second start state in the same machine >> Ben agrees that the Linz notation is wrong. > > I don't know (and don't expect to find out with a reasonable effort) > whay Linz uses the notation he uses. It does not really matter as > the meaning is clear from the text. You may use a better notation if > you know one but constructing a good notation is not easy. As a > test case you may cosider pair of Turing machines that are otherwise > identical but start at different states. > Ben agreed that the Linz notation is wrong back in 2017. The above is my latest draft. embedded_H <is> a copy of Linz H embedded in the middle of Linz Ĥ. >>> Turns out that you can prove that the result produced by Linz' H is >>> different from the result produced by linz' H. This is sufficient to >>> prove that Linz' H does not exist. >>> >>>> This is because the in the latter case embedded_H must determine that >>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly stop running >>>> after 1 to ∞ steps of correct simulation. Thus (as we can all see) >>>> embedded_H meets its abort simulation criteria. >>> >>> Those criteria are not mentioned in Linz' proof and are therefore >>> irrelevant to it. >>> >> >> They are not mentioned because like everyone else Linz rejects >> the notion of a simulating halt decider out-of-hand without review. > > The topic is halt deciders, not simulating halt deciders. If a Actually for a few years now that topic <is> simulating halt deciders. I am the only one that ever bothered to think this through. > simulating halt decider is a halt decider then eerything that > is true about all halt deciders is true about all simulating > halt deciders. No that is false. The details of the behavior of the simulated input do not apply to any decider that does not simulate its input. > The proof that the set of halt deciders is empty Completely ignores that for a simulating halt decider the place where the input contradicts its return value is unreachable. > clearly prves the the set of simulating halt deciders is a > subset of an empty set (or the empty set, as there is only one). > >> When you look for "simulating halt decider" or >> "simulating termination analyzer" you only find me. > > Apparently people do not find subsets of the empty set > very interessting. > People are so sure that I must be wrong that they do not notice that no one found any actual mistakes. The only "mistake" that anyone ever pointed out is essentially "that's not the way that I memorized it". When the behavior of DD correctly simulated by HH is not the same as the behavior of the directly executed DD(DD) they assume the simulation must be wrong even though it it an easily verified fact that it is correct. Mike Terry IS STILL DOING THIS. Mike Terry said the the simulation that was proven to be correct is incorrect because he didn't like the HH code that produced this proven ========== REMAINDER OF ARTICLE TRUNCATED ==========