Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory Subject: Re: ChatGPT and claude.ai agree that I have refuted the conventional Halting Problem proof technique --- Date: Sun, 29 Jun 2025 15:05:37 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <0532e587dab3c2fc441840e64f12e4cc7343622f@i2pn2.org> References: <103acoo$vp7v$1@dont-email.me> <728b9512cbf8dbf79931bfd3d5dbed265447d765@i2pn2.org> <103cvjc$1k41c$1@dont-email.me> <103edbp$22250$5@dont-email.me> <103g91n$2kugi$1@dont-email.me> <103h5dc$2rinm$4@dont-email.me> <103j1di$3bke4$1@dont-email.me> <103l6gv$3ul4b$2@dont-email.me> <103lj0i$14or$1@dont-email.me> <103m8ke$6dce$2@dont-email.me> <103oaov$oscg$3@dont-email.me> <103opgb$rq7e$5@dont-email.me> <103r4r0$2due$1@dont-email.me> <103rf39$1hc53$3@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 29 Jun 2025 19:09:24 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2612884"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird In-Reply-To: <103rf39$1hc53$3@dont-email.me> Content-Language: en-US X-Spam-Checker-Version: SpamAssassin 4.0.0 On 6/29/25 9:29 AM, olcott wrote: > On 6/29/2025 5:34 AM, Fred. Zwarts wrote: >> Op 28.jun.2025 om 15:08 schreef olcott: >>> On 6/28/2025 3:57 AM, Fred. Zwarts wrote: >>>> Op 27.jun.2025 om 16:08 schreef olcott: >>>>> On 6/27/2025 2:59 AM, Fred. Zwarts wrote: >>>>>> Op 27.jun.2025 om 06:26 schreef olcott: >>>>>>> On 6/26/2025 3:46 AM, Fred. Zwarts wrote: >>>>>>>> Op 25.jun.2025 om 17:42 schreef olcott: >>>>>>>>> On 6/25/2025 2:38 AM, Mikko wrote: >>>>>>>>>> On 2025-06-24 14:39:52 +0000, olcott said: >>>>>>>>>> >>>>>>>>>>> *ChatGPT and I agree that* >>>>>>>>>>> The directly executed DDD() is merely the first step of >>>>>>>>>>> otherwise infinitely recursive emulation that is terminated >>>>>>>>>>> at its second step. >>>>>>>>>> >>>>>>>>>> No matter who agrees, the directly executed DDD is mote than >>>>>>>>>> merely the first step of otherwise infinitely recursive >>>>>>>>>> emulation that is terminated at its second step. Not much >>>>>>>>>> more but anyway. After the return of HHH(DDD) there is the >>>>>>>>>> return from DDD which is the last thing DDD does before its >>>>>>>>>> termination. >>>>>>>>>> >>>>>>>>> >>>>>>>>> *HHH(DDD) the input to HHH specifies non-terminating behavior* >>>>>>>>> The fact that DDD() itself halts does not contradict that >>>>>>>>> because the directly executing DDD() cannot possibly be an >>>>>>>>> input to HHH in the Turing machine model of computation, >>>>>>>>> thus is outside of the domain of HHH. >>>>>>>>> >>>>>>>> >>>>>>>> Why repeating claims that have been proven incorrect. >>>>>>>> The input to HHH is a pointer to code, that includes the code of >>>>>>>> HHH, including the code to abort and halt. Therefore, it >>>>>>>> specifies a halting program. >>>>>>> >>>>>>> *No, you are using an incorrect measure* >>>>>>> *I have addressed this too many times* >>>>>> >>>>>> ... with invalid measures. >>>>>> The measure is not whether the simulator can do its job, the >>>>>> measure is what the input specifies. >>>>>> >>>>>>> >>>>>>> DDD correctly simulated by HHH cannot possibly >>>>>>> reach its own simulated "return" statement >>>>>>> final halt state *No matter what HHH does* >>>>>>> Therefore the input to HHH(DD) unequivocally >>>>>>> specifies non-halting behavior. >>>>>>> >>>>>> >>>>>> If the simulator cannot analyse this specification, >>>>> >>>>> *It has been doing this correctly for several years* >>>>> >>>> Another invalid claim without evidence. >>>> Bugs in your program have been pointed out to you for many years, >>>> but you keep dreaming without taking notice of the facts. >>>> The facts are that HHH does not count the conditional branch >>>> instructions, when it is simulating itself. This makes HHH blind for >>>> the specification in the input of the abort done by HHH and the >>>> halting behaviour of the program. >>> >>> HHH reaches its "return" instruction final halt state. >>> >>> DDD correctly simulated by HHH cannot possibly reach >>> its own final halt state no matter what HHH does. >>> >>> You are getting confused over what is being measured. >>> If we were measuring whether or not HHH halts then >>> you would be correct. *We are not measuring that* >>> >> You are confused. If HHH has a bug that does not allow it to reach the >> final halt state of its simulation, then that is not a measure for the >> halting behaviour specified in the input. > > If HHH had a bug then someone could have pointed out the > exact bug on the last two years that its full source has > been available.  https://github.com/plolcott/x86utm > > void DDD() > { >   HHH(DDD); >   return; > } > > _DDD() > [00002192] 55             push ebp > [00002193] 8bec           mov ebp,esp > [00002195] 6892210000     push 00002192 > [0000219a] e833f4ffff     call 000015d2  // call HHH > [0000219f] 83c404         add esp,+04 > [000021a2] 5d             pop ebp > [000021a3] c3             ret > Size in bytes:(0018) [000021a3] > > HHH cannot possibly have a bug because the x86 source > code of DDD specifies that it cannot possibly reach its > "ret" instruction final halt state when emulated by > HHH according to the semantics of the x86 language. Really. Can't have a bug? I guess giving the wrong answer isn't a bug in your view, because you think lies are valid. Note, the x86 source code of DDD says that for *ANY* HHH that exists and returns any value for a call to HHH(DDD), then DDD will halt. Thus, ANY HHH that returns 0 from HHH(DDD) is wromg and has a "bug" It seems your brain has a bug and thinks lies are ok, because the definition of Halting isn't based on the partial emulation of some family of deciders, but only on the behavior of the direct exectuition, which will be copied by any CORRECT simulation/emulation of that program. Of course, by the meaning of the words, the "C function" DDD doesn't have behavior until converted into the PROGRAM DDD by pairing it with a definite version of HHH to call. Something that your buggy logic system doesn't handle, because you seem to have caught a self-inflcted case of terminal stupidity. > >> The bug in HHH has been spelled out to you many times, but it seems >> you close your eyes and pretend that it does not exist. >> The behaviour specified in the exact same input can be analysed in >> different other ways. They all show that the analysis done by HHH is >> incorrect. Therefore, the property(failure) of not being able to reach >> the final halt state is a property of the simulator, not of the >> simulated input. > >