Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!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: Sat, 10 May 2025 18:57:41 -0400 Organization: i2pn2 (i2pn.org) 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 23:18:52 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="4004157"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird Content-Language: en-US X-Spam-Checker-Version: SpamAssassin 4.0.0 In-Reply-To: On 5/10/25 6:03 PM, olcott wrote: > On 5/10/2025 4:44 PM, wij wrote: >> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote: >>> 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* >>>>>>> >>>>>> 10/13/2022> >>>>>>>         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 ========== REMAINDER OF ARTICLE TRUNCATED ==========