Deutsch English Français Italiano |
<vvr3uf$ks69$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Sun, 11 May 2025 16:13:50 -0500 Organization: A noiseless patient Spider Lines: 126 Message-ID: <vvr3uf$ks69$1@dont-email.me> References: <vv97ft$3fg66$1@dont-email.me> <vvnh9u$3hd96$1@raubtier-asyl.eternal-september.org> <vvno4e$3in62$2@dont-email.me> <5b14da4260c0b7e3235ce05f752c092fade4d70e.camel@gmail.com> <vvnsae$3in62$9@dont-email.me> <11cc09876004107c47467b9481f614f45f450f2c.camel@gmail.com> <vvnu9k$3k258$2@dont-email.me> <674a661e498281cca55b322cbd5905a1988a6171.camel@gmail.com> <vvnvut$3kher$3@dont-email.me> <088556c03067d8de7184bf88dd01cc6b8c99ba1b.camel@gmail.com> <vvo1ni$3l14p$1@dont-email.me> <c09f468e8485c22150cedb12a9010b401f292054.camel@gmail.com> <vvo58a$3lnkd$1@dont-email.me> <dc76ef3215a83481dfddc40c466bb9ebc0e77341.camel@gmail.com> <vvo709$3m1oc$1@dont-email.me> <b503e969e23dd1b2a6201ba78c82c9ff7906eaae.camel@gmail.com> <vvo9e8$3m1oc$3@dont-email.me> <b9cec56c1d257e09fdf8043f02f123a4243de6e1.camel@gmail.com> <vvoife$3ofmu$1@dont-email.me> <766e4a7e81e5c70c19b646874c52b62f22438811@i2pn2.org> <vvqjnf$gldn$11@dont-email.me> <f8d15f9ec3c4edd0dbc59f27b4c60c7d759d5a58@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 11 May 2025 23:13:51 +0200 (CEST) Injection-Info: dont-email.me; posting-host="ef7faca461217fa132b1f53eef89d0be"; logging-data="684233"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19lknk82hCV3pDPIWDLHURC" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:kNPzXivnzLKHZe2t2IL0/Z6p9vE= In-Reply-To: <f8d15f9ec3c4edd0dbc59f27b4c60c7d759d5a58@i2pn2.org> X-Antivirus-Status: Clean X-Antivirus: Norton (VPS 250511-4, 5/11/2025), Outbound message Content-Language: en-US Bytes: 7423 On 5/11/2025 3:36 PM, Richard Damon wrote: > On 5/11/25 12:37 PM, olcott wrote: >> 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. > > There is a standardize version of the Turing Machine Language. > > The fact the problem is too big for you to understand just shows that > you are just too stupid to understand it. > > Note, Turing Machines CAN be described at a high level, just like the > OS. And just like understanding the OS with high level code needs an > understanding of the lower level code, understanding the high level > descriptions of Turing Machines needs an understanding of the basic > operaiton of a Turing Machine. > > Since you couldn't handle a Turing Machine of only a few states, that is > about like not being able to understand an assembly function of just a > small number of instructions. > >> >>>> 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. >> > > > First, if that is ALL the input, HHH can't emulate past the call > instruction and be a pure function. > Sure it can. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer