Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: "Fred. Zwarts" Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Tue, 13 May 2025 13:20:58 +0200 Organization: A noiseless patient Spider Lines: 99 Message-ID: References: <5b14da4260c0b7e3235ce05f752c092fade4d70e.camel@gmail.com> <11cc09876004107c47467b9481f614f45f450f2c.camel@gmail.com> <674a661e498281cca55b322cbd5905a1988a6171.camel@gmail.com> <088556c03067d8de7184bf88dd01cc6b8c99ba1b.camel@gmail.com> <766e4a7e81e5c70c19b646874c52b62f22438811@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 13:20:58 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0f93063a85412bb9b83b70aeb6dff6a7"; logging-data="1866990"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19NhpH0e4Yfs7M6hN9DA2s7" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:U60jjTf/eh73HSkDftfhQLYIkIs= In-Reply-To: Content-Language: nl, en-GB Bytes: 6244 Op 11.mei.2025 om 18:37 schreef olcott: > On 5/11/2025 6:07 AM, joes wrote: >> Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott: >>> 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: >> >>>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's >>>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting. >> >> ...which makes it halt. >> >>>>>>>>>>>>>>> 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. >> >> Nobody is baffled. It halts. >> >>>>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> 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) >> >>>>> 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. >>>> Traditional logic (or the part mostly used) that won't cause confusion >>>> is more reliable. >> >> The HP doesn't lead to contradictions. >> >>>>> The halting problem itself remains the same, yet loses its most >>>>> important proof. >>>> >>>> HP is based on TM. Proof of any other kind other than TM have to be >>>> cautious. >>> Unless this is done as an actual simulating termination analyzer in a >>> high level language like C and it operates on a 100% complete exactingly >>> precise input specification such as the x86 language too many details >>> slip through the cracks of vagueness. >> >> TMs are concrete. What details, what vagueness? >> > > There isn't even a common TM language. > If there was a TM language then examining > the details of a termination analyzer would > be like reverse engineering all of the details > of how an operating system works from its > machine code. Humans really need high level > abstractions or they get totally lost. > >>> For example no one ever even noticed that it is 100% impossible to >>> derive an input that actually does the opposite of whatever value that >>> its termination analyzer reports. >> Wrong, DDD calls HHH, which returns "non-halting", *and halts*. >> > > int DD() > { >   int Halt_Status = HHH(DD); >   if (Halt_Status) >     HERE: goto HERE; >   return Halt_Status; > } > > There is no possible way for DD emulated by HHH > according to the rules of the x86 language to > receive the return value from its call to HHH(DDD). > It has been this way for 90 years. > And we all expected this failure of HHH. It is a big support for the halting theorem.