Deutsch English Français Italiano |
<utff3t$1lqsm$5@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: immibis <news@immibis.com> Newsgroups: comp.theory,sci.logic Subject: Re: Proof that H(D,D) meets its abort criteria --induction criteria-- Date: Wed, 20 Mar 2024 20:57:49 +0100 Organization: A noiseless patient Spider Lines: 160 Message-ID: <utff3t$1lqsm$5@dont-email.me> References: <ut1sgk$2buev$2@dont-email.me> <ut8cju$27bqa$8@i2pn2.org> <ut8e9k$8nr$1@dont-email.me> <ut8gic$27bqb$9@i2pn2.org> <ut8go9$l2l$2@dont-email.me> <ut8ide$27bqb$10@i2pn2.org> <ut8j23$t3b$3@dont-email.me> <ut8lhu$27bqa$10@i2pn2.org> <ut9k08$7i77$1@dont-email.me> <ut9li5$7pdg$1@dont-email.me> <ut9ufd$9qc8$2@dont-email.me> <uta5j7$b8d6$1@dont-email.me> <uta7n9$c11s$1@dont-email.me> <uta88f$c3ln$1@dont-email.me> <uta8rr$c91o$1@dont-email.me> <utaam1$ckrm$1@dont-email.me> <utab3j$cn6l$2@dont-email.me> <utac8g$csl0$1@dont-email.me> <utacqt$d328$1@dont-email.me> <utau6c$2b09e$10@i2pn2.org> <utb28m$ksn2$1@dont-email.me> <utb40e$2be23$1@i2pn2.org> <utb4pf$lati$1@dont-email.me> <utciqf$uvmo$1@dont-email.me> <utcklk$v0lj$7@dont-email.me> <utf1so$2gfo0$1@i2pn2.org> <utf2sl$1j44f$1@dont-email.me> <utf907$2gfnv$3@i2pn2.org> <utfa95$1l0lp$1@dont-email.me> <utfcci$1li0p$2@dont-email.me> <utfcq0$1le3h$2@dont-email.me> <utfdmn$1lqsm$2@dont-email.me> <utfe9t$1lpkq$3@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 20 Mar 2024 19:57:49 -0000 (UTC) Injection-Info: dont-email.me; posting-host="da785b61b8e9246896df1af5aa1fe2de"; logging-data="1764246"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19g6ogU6B2o2B2OcTiqM8Xf" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:K5CIBbmJctT1SPSYH8ZutSKP44c= Content-Language: en-US In-Reply-To: <utfe9t$1lpkq$3@dont-email.me> Bytes: 8353 On 20/03/24 20:43, olcott wrote: > On 3/20/2024 2:33 PM, immibis wrote: >> On 20/03/24 20:18, olcott wrote: >>> On 3/20/2024 2:11 PM, Fred. Zwarts wrote: >>>> Op 20.mrt.2024 om 19:35 schreef olcott: >>>>> On 3/20/2024 1:13 PM, Richard Damon wrote: >>>>>> On 3/20/24 12:29 PM, olcott wrote: >>>>>>> On 3/20/2024 11:12 AM, Richard Damon wrote: >>>>>>>> On 3/19/24 2:14 PM, olcott wrote: >>>>>>>>> On 3/19/2024 12:42 PM, immibis wrote: >>>>>>>>>> On 19/03/24 05:37, olcott wrote: >>>>>>>>>>> You are just getting nutty now. You are tossing out the >>>>>>>>>>> sequence, selection, iteration model of computation. >>>>>>>>>> >>>>>>>>>> aren't you tossing out the turing machine model of computation? >>>>>>>>>> >>>>>>>>> >>>>>>>>> I am only tossing out the halting problem specification. >>>>>>>>> I am not saying (like Richard is saying) that sequential >>>>>>>>> code can be executed out-of-sequence. >>>>>>>>> >>>>>>>> >>>>>>>> Just more of your lies. >>>>>>>> >>>>>>>> Where did I say "Sequential Code" can run out-of-sequence. >>>>>>>> >>>>>>>> >>>>>>>> THe codes that I talk about not being in the sequence you think >>>>>>>> are two INDEPENDENT copies of the machines. >>>>>>>> >>>>>>> >>>>>>> The one that is called first is executed first. >>>>>> >>>>>> And I never denied that. >>>>>> >>>>>> But H(D,D) doesn't "Call" D(D), it simulates it. >>>>>> >>>>> >>>>> Thus the steps of D(D) simulated by H come after H(D,D) >>>>> is executed, they do not occur in parallel at the same time. >>>>> >>>>>> The D(D) that it simulates is a machine that has already been >>>>>> "run", since Turing Machines are FULL computation devices that run >>>>>> their procesisng as soon as they are created. >>>>>> >>>>> >>>>> In some strawman deception argument the steps of D(D) come >>>>> before H(D,D) is executed. >>>>> >>>>>> This seems something you don't understand, because you seem to >>>>>> think that D(D) doesn't actually "run" until it is simulated. >>>>>> >>>>> >>>>> The steps of the simulated D(D) are never run, they are only >>>>> simulated. >>>>> In a strawman deception argument the steps of D(D) are executed before >>>>> the steps of H(D,D). >>>>> >>>>>>> >>>>>>>> The H that is deciding the D(D) does not enforce that the ACTUAL >>>>>>>> D(D) it is simulating has not been run yet, and in fact, since >>>>>>>> we can consider Turing Machines to "auto-start" once created, it >>>>>>>> is IMPOSSIBLE to give to H a description of a D(D) that has not >>>>>>>> already run itself. >>>>>>>> >>>>>>> The one that is called first is executed first. >>>>>> >>>>>> So? >>>>>> >>>>> >>>>> You tried to get away with saying otherwise. >>>>> >>>>>> Where does H call D(D)? It SIMULATES it. >>>>>> >>>>>> You seem to think that simulation is the exact same thing as >>>>>> EXECUTION. >>>>>> >>>>>>> >>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts >>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not >>>>>>> halt >>>>>>> >>>>>>> Ĥ ⟨Ĥ⟩ is executed before Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ thus the executed Ĥ ⟨Ĥ⟩ is >>>>>>> run before the simulated one. When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ simulates its input >>>>>>> it can see that it must abort this simulation. >>>>>> >>>>>> Yes H^ (H^) is executed before H^.H (H^) (H^) but the instance of >>>>>> the machine represented by that input was executed when it was >>>>>> created, so has already run. >>>>>> >>>>> Unless you are trying to get away with rejecting the sequence of >>>>> sequence, selection, iteration you already know that Ĥ ⟨Ĥ⟩ is always >>>>> executed before Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩. >>>>> >>>>>> Again, you are confusing the simulation that H, or H^.H does, with >>>>>> the axtual execution of them. >>>>>> >>>>>> You could even look at the simulation of H^.H as telling H part of >>>>>> what this H^ (H^) has alteady done. >>>>>> >>>>>> >>>>>>> >>>>>>>> We, as finite humans may not know what it did, but the >>>>>>>> mathematical world of truth does. >>>>>>>> >>>>>>> >>>>>>> Mathematical induction proves that after N steps of correct >>>>>>> simulation >>>>>>> H correctly determines that ∞ steps of correct simulation would >>>>>>> never >>>>>>> halt. *These are verified facts that you perpetually deny* >>>>>> >>>>>> NOPE. >>>>>> >>>>>> STATE YOUR INDUCTION CRITERIA and their proof >>>>>> >>>>> >>>>> As soon as H(D,D) sees that D calls itself with its same inputs >>>>> and there are no conditional branch instructions from the >>>>> beginning of D to its call to H(D,D) then H knows that its >>>>> simulated D(D) cannot possibly reach its own final instruction >>>>> (at line 06) in any finite number of steps of correct simulation. >>>> >>>> An infinite recursion could be detected if a program comes back at >>>> the same place in the same state. In this case the beginning of D >>>> and the call to H are not the same place within the program. What >>>> Olcott means, but does not say, is that the call from D to H causes >>>> the program to arrive at a similar place in a similar state as when >>>> H (not D) started. But now we see that there are conditional branch >>>> instructions between these two places, namely within H, which may >>>> cause an end of the recursion. In fact, it is known that the >>>> recursion is not infinite, but does end, because H aborts and returns. >>> >>> There are no conditional branch instructions that allow >>> the simulated D(D) to reach its own final state and halt. >> >> There is a conditional branch instruction which causes the simulated >> H(D,D) to reach its final state and return 0. However, > >> the simulation of H(D,D) is aborted before the simulated H(D,D) >> reaches this instruction. >> > > That proves a lack of sufficient software engineering skills. > What are your programming skills? > > I have been a professional developer since 1984 and a professional > C++ software engineer since 2000. Ad hominem deception rejected. > >>> >>> In fact neither the simulated D(D) nor the executed H(D,D) can >>> possibly stop running unless the executed H(D,D) aborts its >>> simulation without waiting for any simulated H(D,D) to do this. >>> >> >