Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Sat, 10 May 2025 14:29:12 -0500 Organization: A noiseless patient Spider Lines: 177 Message-ID: References: <875xiaejzg.fsf@nosuchdomain.example.com> <87jz6qczja.fsf@nosuchdomain.example.com> <5b14da4260c0b7e3235ce05f752c092fade4d70e.camel@gmail.com> <11cc09876004107c47467b9481f614f45f450f2c.camel@gmail.com> <674a661e498281cca55b322cbd5905a1988a6171.camel@gmail.com> <088556c03067d8de7184bf88dd01cc6b8c99ba1b.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 10 May 2025 21:29:13 +0200 (CEST) Injection-Info: dont-email.me; posting-host="7be348abb5bc2ec0a70724586a3ca680"; logging-data="3868428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19VXFyrywyBEqHZohpPRKhe" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:RQNbsrJOOQlUhgc7wJBL17iMfUk= In-Reply-To: X-Antivirus-Status: Clean Content-Language: en-US X-Antivirus: Norton (VPS 250510-4, 5/10/2025), Outbound message Bytes: 9329 On 5/10/2025 2:02 PM, wij wrote: > On Sat, 2025-05-10 at 13:47 -0500, olcott wrote: >> On 5/10/2025 1:37 PM, wij wrote: >>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote: >>>> On 5/10/2025 1:09 PM, wij wrote: >>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote: >>>>>> On 5/10/2025 12:01 PM, wij wrote: >>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote: >>>>>>>> On 5/10/2025 11:29 AM, wij wrote: >>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote: >>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote: >>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote: >>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote: >>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote: >>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote: >>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Look at their replies to this post. >>>>>>>>>>>>>>>> Not a one of them will agree that >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> void DDD() >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>          HHH(DDD); >>>>>>>>>>>>>>>>          return; // final halt state >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> When 1 or more instructions of DDD are correctly >>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot >>>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt state). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> They have consistently disagreed with this >>>>>>>>>>>>>>>> simple point for three years. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I guess that not even a professor of theoretical computer >>>>>>>>>>>>>>> science would spend years working on so few lines of code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I created a whole x86utm operating system. >>>>>>>>>>>>>> It correctly determines that the halting problem's >>>>>>>>>>>>>> otherwise "impossible" input is actually non halting. >>>>>>>>>>>>>> >>>>>>>>>>>>>> int DD() >>>>>>>>>>>>>> { >>>>>>>>>>>>>>          int Halt_Status = HHH(DD); >>>>>>>>>>>>>>          if (Halt_Status) >>>>>>>>>>>>>>            HERE: goto HERE; >>>>>>>>>>>>>>          return Halt_Status; >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/plolcott/x86utm >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Nope. >>>>>>>>>>>>>       From I know HHH(DD) decides whether the input DD is "impossible" input >>>>>>>>>>>>> or >>>>>>>>>>>>> not. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> DD has the standard form of the "impossible" input. >>>>>>>>>>>> HHH merely rejects it as non-halting. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You said 'merely' rejects it as non-halting. >>>>>>>>>>> So, POOH do not answer the input of any other function? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The input that has baffled computer scientists for 90 >>>>>>>>>> years is merely correctly determined to be non-halting >>>>>>>>>> when the behavior of this input is measured by HHH >>>>>>>>>> emulating this input according to the rules of the x86 >>>>>>>>>> language. >>>>>>>>>> >>>>>>>>>> The same thing applies to the Linz proof yet cannot >>>>>>>>>> be understood until after HHH(DDD) and HHH(DD) are >>>>>>>>>> fully understood. >>>>>>>>>> >>>>>>>>> >>>>>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input. >>>>>>>>> Others of what you say are your imagine and wishes, so far so true. >>>>>>>>> >>>>>>>> >>>>>>>> DDD emulated by HHH accor not the 'HHH' that makes the final decision >>>>> (otherwise, it will be an infinite recursive call which you agreed) >>>>> >>>>>>>> ding to the rules of >>>>>>>> the x86 language specifies recursive emulation >>>>>>>> that cannot possibly reach the final halt state >>>>>>>> of DDD. >>>>>>>> >>>>>>> >>>>>>> I have no problem with that. And, you said HHH merely rejects it as non-halting. >>>>>>> You had denied HHH can decide the halting property of any input, except DDD/DD/D.. >>>>>>> >>>>>> >>>>>> As long as HHH correctly determines the halt status >>>>>> of a single input that has no inputs then HHH is >>>>>> a correct termination analyzer for that input. >>>>> >>>>> Go it, that is a stronger statement that HHH ONLY decides DD. >>>>> I have no problem with that, but be noticed that the HHH inside DD >>>>> is not the 'HHH' that makes the final decision (otherwise, the 'HHH' >>>>> will be an infinite recursive which cannot make any decision, which >>>>> you had agreed) >>>>> >>>> >>>> HHH(DD) correctly determines that its input specifies >>>> recursive emulation when this input is emulated by HHH >>>> HHH according to the rules of the x86 language. >>> >>>  From the about, so you are talking about 'the HHH' which does not compute the final decision. >>> >> >> HHH does recognize the recursive emulation pattern >> of DDD emulated by HHH according to the rules of >> the x86 language. >> >>>> *Thus exactly meets the following specification* >>>> >>>>       If simulating halt decider H correctly simulates its >>>>       input D until H correctly determines that its simulated D >>>>       would never stop running unless aborted then >>>> >>>>       H can abort its simulation of D and correctly report that D >>> >>> This H won't be the same HHH inside the DD, otherwise an infinite recursive call happens. >>> >> >> It must always be the outermost HHH that does this >> because it has seen one entire recursive emulation >> more than the next inner HHH. > > No problem. H is not HHH. > The H is the template that Professor Sipser agreed to. HHH is a specific implementation of H. > This is also a pitty no one here understand POOH can help AI industry and mankind, even so mini. > It is the same halting problem after its mistake has been corrected. So just like how ZFC corrected the error in set theory so that Russell's Paradox could be correctly decided, HHH corrects the error in the halting problem proof so that the otherwise impossible input is correctly decided. The original set theory is now called naive set theory after its mistake has been corrected. Thus the original halting problem proofs can now be called the naive halting problem proofs. The halting problem itself remains the same, yet loses its most important proof. >>>>       specifies a non-halting sequence of configurations. >>>> >>>> ========== REMAINDER OF ARTICLE TRUNCATED ==========