Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory,comp.ai.philosophy,sci.logic Subject: Halting Problem Proof ERROR Date: Thu, 17 Jul 2025 09:44:23 -0500 Organization: A noiseless patient Spider Lines: 193 Message-ID: <105b287$1dh7g$1@dont-email.me> References: <102sjg5$2k3e9$1@dont-email.me> <104041c$2nne5$1@dont-email.me> <1040hq4$2ql69$3@dont-email.me> <1042l0e$3cik5$1@dont-email.me> <1046v71$ctak$1@dont-email.me> <1047vld$n4s2$1@dont-email.me> <1048hp0$qd4f$2@dont-email.me> <66c00d5703907e846f537310dfb201485e1b7b2a@i2pn2.org> <10492eb$u8g5$1@dont-email.me> <104b5l9$fnl$1@news.muc.de> <104ben3$1hqln$1@dont-email.me> <104bt5h$1l1g$1@news.muc.de> <104bunk$1kcb5$1@dont-email.me> <104did7$hlh$1@news.muc.de> <104e164$2852a$1@dont-email.me> <104e6nd$12ua$1@news.muc.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 17 Jul 2025 16:44:24 +0200 (CEST) Injection-Info: dont-email.me; posting-host="757a756c4546e5542c44a33ac5ff5463"; logging-data="1492208"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/xD3cLEspc9MryBu1hvtCW" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:6LCxH56nviiMMTu4n5oHjDwfbig= In-Reply-To: <104e6nd$12ua$1@news.muc.de> X-Antivirus-Status: Clean Content-Language: en-US X-Antivirus: Norton (VPS 250717-2, 7/17/2025), Outbound message On 7/6/2025 11:02 AM, Alan Mackenzie wrote: > [ Followup-To: set ] > > In comp.theory olcott wrote: >> On 7/6/2025 5:16 AM, Alan Mackenzie wrote: >>> olcott wrote: >>>> On 7/5/2025 2:07 PM, Alan Mackenzie wrote: > >>>>> You lie. You don't have a proof. Many people in this group have pointed >>>>> out lots of errors in various versions of your purported proof, which you >>>>> just ignore. The section in Professor Linz's book you used to be so fond >>>>> of citing will contain plenty of details, if only you would take the >>>>> trouble to understand it (assuming you're capable of such understanding). > >>>> I have addressed .... > >>> Meaningless pompous word. > >>>> .... all of those details that you make sure to ignore so that you can >>>> baselessly claim that I am wrong. > >>> I vaguely remember rolling my eyes at your hopeless lack of >>> understanding. It was like watching a 7 year old trying to do calculus. >>> The basic understanding was simply not there. Years later, it's still >>> not there. > >>> And yes, you are wrong. The proofs of the halting theorem which involve >>> constructing programs which purported halting deciders cannot decide >>> correctly are correct. > >> Yet you cannot point to even one mistake because there are none. > > That's what I'm saying. Those proofs of the halting theorem are free > from mistakes. > > More to the point, it is YOU who cannot point to any mistakes in them. > They are valid proofs. Your work, if it contradicts those proofs (which > isn't at all clear) can thus be dismissed without further consideration. > >>>> There cannot possibly be *AN ACTUAL INPUT* that does the >>>> opposite of whatever its decider decides. All of the examples >>>> of this have never been *ACTUAL INPUTS* > >>> That's so sloppily worded, it could mean almost anything. > >> The standard halting problem proof cannot even be constructed. > > It has been constructed, and is valid. But one would normally talk about > formulating a proof, rather than constructing one. > > [ .... ] > >>>> No Turing machine can possibly take another directly executing >>>> Turing machine as in input, thus removing these from the >>>> domain of every halt decider. > >>> And that, too. > >>>> *Thus the requirement that HHH report on the behavior* >>>> *of the directly executed DD has always been bogus* > >>> And that makes your hat trick. > >>>> Turing machine partial halt deciders compute the mapping >>>> from their actual inputs to the actual behavior that these >>>> inputs specify. > >>> And a fourth. There's some semblance of truth in there, but it's very >>> confused. > > >> It is not at all confused. I know exactly what it means. > > It's very confused to everybody but you, then. > >>> Sloppy wording is your technique to get people to go down to your level >>> of discussion. That involves many posts trying just to tie you down to >>> specific word meanings, and is very tiresome and unrewarding. I decline >>> to get involved any further. > > >> *Yet as I claimed you found no actual mistake* > > I've found plenty of actual mistakes. I was a software developer by > profession. > >> Let me tell you the punchline so that you can >> see why I said those things. > > Despite what I said last post, I will actually go to the trouble of > analysing your sloppy expression. > >> Because directly executed Turing machines cannot >> possibly be inputs to Turing machine deciders this >> makes them outside of the domain of these deciders. > > It's entirely unclear what a "directly executed Turing machine" is. Most > of the time turing machines are theoretical constructs used for proving > theorems. They can be executed, but rarely are. > > It's unclear what you mean by a turing machine being an input to a turing > machine. Read up about universal turing machines to get a bit of > background. > >> When a partial halt decider is required to report >> on the direct execution of a machine this requirement >> is bogus. > > See above. That paragraph is meaningless. > >> This means that the behavior of DD() is none of the damn >> business of HHH, thus does not contradict HHH(DD)==0. >> *If you disagree this only proves that you do not understand* > > It's fully obscure what DD() and HHH mean, and thus impossible to > affirm or contradict the meaningless "HHH(DD)==0". > >> HHH(DD) does correctly detect that DD simulated by HHH >> according to the semantics pf the C programming language >> cannot possibly reach its own "return"statement final >> halt state. > > See above. By the way, people concerned with computation theory use > turing machines, which are well-defined, simple, and powerful. They lack > the complexity, ambiguity, and unsuitability for theoretical work of real > world programming languages like C. > >> *If you disagree this only proves that you do not understand* > >> Any mindless idiot can disagree. Showing an error and proving >> that it is an actual mistake requires much more than this. > > Indeed. All you have done is disagree with one of the proofs of the > halting theorem. You have yet to show an error in it. That will be > difficult, because there aren't any. > q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞, if M applied to WM halts, and q0 WM ⊢* Ĥq0 Wm WM ⊢* Ĥ y1 qn y2, if M applied to WM does not halt. *From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, if Ĥ applied to ⟨Ĥ⟩ halts, and Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt. <*Halting Problem Proof ERROR*> Requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report on the direct execution of Ĥ applied to ⟨Ĥ⟩ and thus not ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H. No Turing Machine decider can ever report on the behavior of anything that is not an input encoded as a finite string. Ĥ is not a finite string input to Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ are finite string inputs to Ĥ.embedded_H Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches its simulated final halt state of ⟨Ĥ.qn⟩, and Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn ========== REMAINDER OF ARTICLE TRUNCATED ==========