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 13:47:36 -0500 Organization: A noiseless patient Spider Lines: 146 Message-ID: References: <87msbmeo3b.fsf@nosuchdomain.example.com> <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 20:47:37 +0200 (CEST) Injection-Info: dont-email.me; posting-host="7be348abb5bc2ec0a70724586a3ca680"; logging-data="3868428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19WBtUINUdjWN4p/2MCNyWL" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:LdazlqxuThwn97eF1qBFM8sTTMQ= In-Reply-To: X-Antivirus-Status: Clean X-Antivirus: Norton (VPS 250510-4, 5/10/2025), Outbound message Content-Language: en-US Bytes: 8106 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. >>      specifies a non-halting sequence of configurations. >> >> >> Professor Sipser is the best selling author of theory of >> computation textbooks. >> It is a pity that he could never take the five more minutes >> required to understand the notion of recursive emulation and >> thus see the significance of my work. > > You can cite any one, I don't know who Sipsper is. > But yes, it is also a pity that Socrites and Turing did not know POOH. > https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer