Deutsch English Français Italiano |
<vvrmcf$s0mk$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: dbush <dbush.mobile@gmail.com> Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Sun, 11 May 2025 22:28:31 -0400 Organization: A noiseless patient Spider Lines: 135 Message-ID: <vvrmcf$s0mk$2@dont-email.me> References: <vv97ft$3fg66$1@dont-email.me> <87msbmeo3b.fsf@nosuchdomain.example.com> <vvjcge$27753$2@dont-email.me> <vvjeqf$28555$1@dont-email.me> <vvjffg$28g5i$1@dont-email.me> <875xiaejzg.fsf@nosuchdomain.example.com> <vvjgt1$28g5i$5@dont-email.me> <87jz6qczja.fsf@nosuchdomain.example.com> <vvjotc$28g5i$12@dont-email.me> <vvnh9u$3hd96$1@raubtier-asyl.eternal-september.org> <vvno4e$3in62$2@dont-email.me> <vvo71c$rlt$1@news.muc.de> <PlNTP.270466$lZjd.128570@fx05.ams4> <vvochv$15td$2@news.muc.de> <vvodn5$3na6l$3@dont-email.me> <1276edeb9893085c59b02bbbd59fe2c64011736b@i2pn2.org> <vvqk4s$gldn$12@dont-email.me> <vvqln4$g8ck$5@dont-email.me> <vvrftj$ndkg$1@dont-email.me> <vvrggs$n9a9$3@dont-email.me> <aa56821a00afb05081a2f4684d4ad8fefc9b2376@i2pn2.org> <vvrkg9$o2ab$3@dont-email.me> <vvrkm9$mv2a$7@dont-email.me> <vvrli3$s6gd$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 12 May 2025 04:28:31 +0200 (CEST) Injection-Info: dont-email.me; posting-host="d587ba6f088c47ed8fd2ad250ebfd646"; logging-data="918228"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+FXChHRuEG/CH49R3dFnPj" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:xGX3Rmuvkz62vv7aNCX55gNWHZI= Content-Language: en-US In-Reply-To: <vvrli3$s6gd$1@dont-email.me> On 5/11/2025 10:14 PM, olcott wrote: > On 5/11/2025 8:59 PM, dbush wrote: >> On 5/11/2025 9:56 PM, olcott wrote: >>> On 5/11/2025 8:27 PM, Richard Damon wrote: >>>> On 5/11/25 8:48 PM, olcott wrote: >>>>> On 5/11/2025 7:38 PM, Mike Terry wrote: >>>>>> On 11/05/2025 18:11, Richard Heathfield wrote: >>>>>>> On 11/05/2025 17:44, olcott wrote: >>>>>>>> Any yes/no question where both yes and no are the >>>>>>>> wrong answer is an incorrect polar question. >>>>>>> >>>>>>> Either DD stops or it doesn't (once it's been hacked around to >>>>>>> get it to compile and after we've leeched out all the dodgy >>>>>>> programming). >>>>>> >>>>>> Done that. It still stops. >>>>>> >>>>>>> >>>>>>> If the computer cannot correctly decide whether or not DD halts, >>>>>> >>>>>> The decider says it doesn't stop.. >>>>>> >>>>>>> we have an undecidable computation, >>>>>> >>>>>> No no, that doesn't make sense. DD stops, and there are lots of >>>>>> partial halt deciders that will decide that particular input >>>>>> correctly. PO's DD isn't "undecidable". >>>>>> >>>>>> No single computation can be undecidable, considered on its own! >>>>>> There are only two possibilities: it halts or it doesn't. In >>>>>> either case there is a decider which decides that /one specific >>>>>> input/ correctly. By extension, any finite number of computations >>>>>> is decidable - we just have a giant switch statement followed by >>>>>> returning halts/neverhalts as appropriate. If the input domain >>>>>> has just n inputs, there are 2^n trivial deciders that together >>>>>> cater for every combination of each input halting or never >>>>>> halting. One of those deciders is a correct decider for that >>>>>> (finite domain) problem. >>>>>> >>>>>> The HP is asking for a TM (or equiv.) that correctly decides EVERY >>>>>> (P,I) in its one finite algorithm. That is what is proven >>>>>> impossible. The trick of having a big switch statement no longer >>>>>> works because there are infinitely many possible inputs. >>>>>> >>>>>> Decidability for just one single input is trivial and not intersting. >>>>>> >>>>>>> and therefore some computations are undecidable, so Turing's >>>>>>> conclusion was right. Who knew? (Apart from practically everybody >>>>>>> else, I mean.) >>>>>> >>>>>> >>>>>> Mike. >>>>> >>>>> DDD emulated by HHH according to the rules of >>>>> the computational language that DD is encoded >>>>> within already proves that the HP "impossible" >>>>> input specifies a non-halting sequence of >>>>> configurations. >>>> >>>> No it doesn't. >>>> >>> >>> _DDD() >>> [00002172] 55 push ebp ; housekeeping >>> [00002173] 8bec mov ebp,esp ; housekeeping >>> [00002175] 6872210000 push 00002172 ; push DDD >>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>> [0000217f] 83c404 add esp,+04 >>> [00002182] 5d pop ebp >>> [00002183] c3 ret >>> Size in bytes:(0018) [00002183] >>> >>> Show all the steps of DDD emulated by simulating >>> termination analyzer HHH according to the rules >>> of the x86 language >> >> Which it doesn't do as you have admitted on the record: >> > > I am daring you to show what they should be. > You know you can't because you know you are a liar. > Category error. Algorithm HHH does one thing and one thing only. There is no "what it should be" because it *is* only one thing. Algorithm HHH *does not* perform a correct simulation of algorithm DDD due to the abort, as you have admitted on the record: >> On 5/5/2025 8:24 AM, dbush wrote: >> > On 5/4/2025 11:03 PM, dbush wrote: >> >> On 5/4/2025 10:05 PM, olcott wrote: >> >>> On 5/4/2025 7:23 PM, Richard Damon wrote: >> >>>> But HHH doesn't correct emulated DD by those rules, as those rules >> >>>> do not allow HHH to stop its emulation, >> >>> >> >>> Sure they do you freaking moron... >> >> >> >> Then show where in the Intel instruction manual that the execution of >> >> any instruction other than a HLT is allowed to stop instead of >> >> executing the next instruction. >> >> >> >> Failure to do so in your next reply, or within one hour of your next >> >> post on this newsgroup, will be taken as you official on-the-record >> >> admission that there is no such allowance and that HHH does NOT >> >> correctly simulate DD. >> > >> > Let the record show that Peter Olcott made the following post in this >> > newsgroup after the above message: >> > >> > On 5/4/2025 11:04 PM, olcott wrote: >> > > D *WOULD NEVER STOP RUNNING UNLESS* >> > > indicates that professor Sipser was agreeing >> > > to hypotheticals AS *NOT CHANGING THE INPUT* >> > > >> > > You are taking >> > > *WOULD NEVER STOP RUNNING UNLESS* >> > > to mean *NEVER STOPS RUNNING* that is incorrect. >> > >> > And has made no attempt after over 9 hours to show where in the Intel >> > instruction manual that execution is allowed to stop after any >> > instruction other than HLT. >> > >> > Therefore, as per the above criteria: >> > >> > LET THE RECORD SHOW >> > >> > That Peter Olcott >> > >> > Has *officially* admitted >> > >> > That DD is NOT correctly simulated by HHH