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 17:03:26 -0500 Organization: A noiseless patient Spider Lines: 235 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: Sun, 11 May 2025 00:03:27 +0200 (CEST) Injection-Info: dont-email.me; posting-host="ef7faca461217fa132b1f53eef89d0be"; logging-data="3948254"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Spa0YZNIqhPVRlbU8t3u3" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:dK6j0Q5N6w4sPHRjzLBNhxXNVF0= Content-Language: en-US In-Reply-To: X-Antivirus-Status: Clean X-Antivirus: Norton (VPS 250510-4, 5/10/2025), Outbound message Bytes: 11803 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* >>>>>> >>>>>>        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. > > I don't know what that part of set theory works. > (My feeling is that they are garbage, for reasons, > unless you are doing logic researches) > >> The original set theory is now called naive set >> theory after its mistake has been corrected. Thus ========== REMAINDER OF ARTICLE TRUNCATED ==========