Deutsch English Français Italiano |
<v3f9ha$2qh0t$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory,sci.logic Subject: Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Date: Sat, 1 Jun 2024 09:00:08 -0500 Organization: A noiseless patient Spider Lines: 166 Message-ID: <v3f9ha$2qh0t$1@dont-email.me> References: <v3501h$lpnh$1@dont-email.me> <v37bpa$15n0b$1@dont-email.me> <v37i9p$lls$1@news.muc.de> <87y17smqnq.fsf@bsb.me.uk> <v37sap$18mfo$1@dont-email.me> <v38eq4$2foi0$1@i2pn2.org> <v38fe0$1bndb$1@dont-email.me> <v38g31$2foi0$11@i2pn2.org> <v38gi5$1bndb$3@dont-email.me> <v38ici$2fohv$2@i2pn2.org> <v38j17$1c8ir$2@dont-email.me> <v38jgo$2foi0$14@i2pn2.org> <v38jv9$1c8ir$4@dont-email.me> <v39agi$1jiql$1@dont-email.me> <v39v3h$1mtd9$5@dont-email.me> <v3b9kj$2im02$1@i2pn2.org> <v3bale$222n5$1@dont-email.me> <v3bbs2$2im01$1@i2pn2.org> <v3bcre$22a8n$1@dont-email.me> <v3bduk$2im01$2@i2pn2.org> <v3bedb$22f8h$1@dont-email.me> <v3bfbm$2im01$3@i2pn2.org> <v3bg39$22o6m$1@dont-email.me> <v3cbhu$2k3ld$1@i2pn2.org> <v3clo2$28p7n$1@dont-email.me> <v3dft1$2lfup$1@i2pn2.org> <v3dhob$2dio8$1@dont-email.me> <v3dk0d$2lfup$2@i2pn2.org> <v3dkf2$2e2po$1@dont-email.me> <v3dmnc$2lfup$3@i2pn2.org> <v3do66$2ejq2$1@dont-email.me> <MPG.40c4fbcb474992459896fd@reader.eternal-september.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 01 Jun 2024 16:00:11 +0200 (CEST) Injection-Info: dont-email.me; posting-host="5617c6a52e82e3edb2307f1199229213"; logging-data="2966557"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX199gEns5EJTEIPOQapcES/Q" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:UWyM2dP792TkwcgSfgJ/f0xC9ak= Content-Language: en-US In-Reply-To: <MPG.40c4fbcb474992459896fd@reader.eternal-september.org> Bytes: 8543 On 6/1/2024 3:36 AM, Wasell wrote: > On Fri, 31 May 2024 18:57:57 -0500, in article <v3do66$2ejq2$1@dont-email.me>, > olcott wrote: >> >> On 5/31/2024 6:33 PM, Richard Damon wrote: > > [...] > >>> Never said it could. But haven't looked hard enough to be willing to say >>> it can't, but then, who cares, it doesn't say a thing about the real >>> halting problem, since H's simulation isn't "correct" by a definition >>> that relates simulation to non-halting behavior, >> >> "...the Turing machine will halt whenever it enters a final state." >> Linz(1990:234) >> >> *If DD correctly simulated by HH can't possibly reach its own* >> *final state then DD correctly simulated by HH is non-halting* > > You keep using this quote as if it means that the /only/ way a TM > can halt, is if it enters a final state. You never quote the > context: > > "A Turing machine is said to halt whenever it reaches a > configuration for which \delta is not defined; this is possible > because \delta is a partial function. In fact, we will assume that > no transitions are defined for any final state, so the Turing > machine will halt whenever it enters a final state." > (p. 227 in my copy) > > This means that a TM /will/ halt if it enters a final state, but it > can also halt in other states. This interpretation is confirmed in > other places in Linz: > > "The machine can halt in a nonfinal state or it can enter an > infinite loop and never halt. [...] we halt in a nonfinal state. > [...] the machine will halt in the nonfinal state q_0 , since > \delta(q_0,1) is undefined." (p. 232) > > "[...] the computation will halt in a nonfinal state." (p. 233) > > "Other input not in the language will also lead to a nonfinal > halting state" (p. 234) > > "[...] that will halt in a nonfinal state q_n if x < y." (p. 237) > > etc, etc. > > Can I expect you to never use this deceptive out-of-context quote > ever again? DD correctly simulated by HH remains stuck in recursive simulation all the time it is simulated even when an infinite number of steps are simulated. According to the words that you quoted it would be more accurate to provide a longer definition. I will attempt that yet this may be too difficult for my short-attention space reviewers. "δ is the transition function" (Linz:1990:233) ... "A Turing machine is said to halt whenever it reaches a configuration for which δ is not defined; (Linz:1990:234) DD correctly simulated by HH never reaches any point where δ is not defined. My target audience of software engineers may be dumbfounded by that. Software engineers will not allow false assumptions to override verified facts. DD correctly simulated by HH has behavior that is isomorphic to Infinite_Recursion simulated by HH. void Infinite_Recursion(u32 N) { Infinite_Recursion(N); } Since the idea of a simulating halt decider is brand new with me there is not any preexisting literature on simulating halt deciders. The above proves that we cannot construe that stopping running because of stopping being simulated is any kind of halting behavior. Introduction to the Theory of Computation, by Michael Sipser https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/ On 10/13/2022 11:29:23 AM MIT Professor Michael Sipser agreed that these verbatim words are correct (He has neither reviewed nor agreed to anything else in this paper) <Sipser agreed> 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 specifies a non-halting sequence of configurations. </Sipser agreed> Because my reviewers tend to be much more interested in rebuttal (even when this rebuttal directly contradicts verified facts) I must make my words unequivocal and clear. Even when make my words unequivocally prove my point with verified facts they still disagree. After three years of discussion with Richard on the one point that DD correctly simulated by HH never reaches its own final state he finally admitted that he just doesn't. I had to confront him with the x86 machine code of DD to get him to concede that he doesn't know. This took three years. Prior to confronting him with this machine code he (and two dozen other people) persistently disagreed with what a correct simulation is. Now that the machine code is presented no one can get away with saying that DD correctly simulated by HH can possibly reach its own machine address of 00001c47 (or any other point where δ is undefined). typedef int (*ptr)(); // ptr is pointer to int function in C 00 int HH(ptr p, ptr i); 01 int DD(ptr p) 02 { 03 int Halt_Status = HH(p, p); 04 if (Halt_Status) 05 HERE: goto HERE; 06 return Halt_Status; 07 } It is clear that DD correctly simulated by HH using an x86 emulator cannot possibly reach past its own line 03 for 1 to ∞ steps of correct simulation. Four experts in the C language concurred with my own expert assessment. It really is dead obvious to anyone with sufficient knowledge of the C programming language thus all those that disagree could only be playing trollish head games. Finally when confronted with the x86 machine language of DD where lying would look ridiculously foolish Richard backed down and admitted that he just doesn't know. _DD() [00001c22] 55 push ebp [00001c23] 8bec mov ebp,esp [00001c25] 51 push ecx [00001c26] 8b4508 mov eax,[ebp+08] [00001c29] 50 push eax ; push DD 1c22 [00001c2a] 8b4d08 mov ecx,[ebp+08] [00001c2d] 51 push ecx ; push DD 1c22 [00001c2e] e80ff7ffff call 00001342 ; call HH [00001c33] 83c408 add esp,+08 [00001c36] 8945fc mov [ebp-04],eax [00001c39] 837dfc00 cmp dword [ebp-04],+00 [00001c3d] 7402 jz 00001c41 [00001c3f] ebfe jmp 00001c3f [00001c41] 8b45fc mov eax,[ebp-04] [00001c44] 8be5 mov esp,ebp [00001c46] 5d pop ebp [00001c47] c3 ret Size in bytes:(0038) [00001c47] ========== REMAINDER OF ARTICLE TRUNCATED ==========