Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Mon, 12 May 2025 22:42:04 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <1a237cee25a04881fe362c6cfd4e809b94ae1277@i2pn2.org> References: <87msbmeo3b.fsf@nosuchdomain.example.com> <875xiaejzg.fsf@nosuchdomain.example.com> <87jz6qczja.fsf@nosuchdomain.example.com> <1276edeb9893085c59b02bbbd59fe2c64011736b@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 13 May 2025 03:53:51 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="124170"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US In-Reply-To: Bytes: 5275 Lines: 97 On 5/11/25 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] Not a valid input, > > Show all the steps of DDD emulated by simulating > termination analyzer HHH according to the rules > of the x86 language where the emulated DDD reaches > its "ret" instruction. Why? That isn't the criteria. > > You can't only because you know that you are > lying about this. No, I am pointing out your stupidity, and you just repeat it to make it more obvious. > > Your static data trick was clever yet your HHH > was not a simulating termination analyzer. > Sure it was. At the outer layer it fully emulates its input. That is more than yours does. Of course, your concept of that is just a category error and a lie.