Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Sun, 11 May 2025 19:34:41 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: <09cea75db07408dc9203aca3fb74408ad3a095b4.camel@gmail.com> <853816e160c7b3fe75c71f0728e72989d9fb2e41.camel@gmail.com> <41e08841caf0d628beb5105bc78531a412eea440.camel@gmail.com> <07c4f2302645a7e58957b5e5bffed80397a6ddae.camel@gmail.com> <04bd32e2a5572305de0376f9569172932ffb252f.camel@gmail.com> <72f8c8295d3a0ff265a67b0de838516ade16c6d5.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 11 May 2025 23:39:57 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="4145107"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US In-Reply-To: Bytes: 11478 Lines: 230 On 5/11/25 6:00 PM, olcott wrote: > On 5/11/2025 4:48 PM, wij wrote: >> On Sun, 2025-05-11 at 15:53 -0500, olcott wrote: >>> On 5/11/2025 3:23 PM, wij wrote: >>>> On Sun, 2025-05-11 at 15:19 -0500, olcott wrote: >>>>> On 5/11/2025 1:38 PM, wij wrote: >>>>>> On Sun, 2025-05-11 at 12:40 -0500, olcott wrote: >>>>>>> On 5/11/2025 12:21 PM, wij wrote: >>>>>>>> On Sun, 2025-05-11 at 12:00 -0500, olcott wrote: >>>>>>>>> On 5/11/2025 11:28 AM, wij wrote: >>>>>>>>>> On Sun, 2025-05-11 at 10:38 -0500, olcott wrote: >>>>>>>>>>> On 5/11/2025 9:34 AM, wij wrote: >>>>>>>>>>>> On Sat, 2025-05-10 at 21:19 -0500, olcott wrote: >>>>>>>>>>>>> On 5/10/2025 9:09 PM, wij wrote: >>>>>>>>>>>>>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote: >>>>>>>>>>>>>>> On 5/10/2025 8:44 PM, wij wrote: >>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 5/10/2025 8:17 PM, wij wrote: >>>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 17:03 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>> 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: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> You don't know the counter example in the HP proof, >>>>>>>>>>>>>>>>>> your D is not the >>>>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>>>> what HP >>>>>>>>>>>>>>>>>> says. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sure I do this is it! (as correctly encoded in C) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> typedef void (*ptr)(); >>>>>>>>>>>>>>>>> int HHH(ptr P); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> int DD() >>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>            int Halt_Status = HHH(DD); >>>>>>>>>>>>>>>>>            if (Halt_Status) >>>>>>>>>>>>>>>>>              HERE: goto HERE; >>>>>>>>>>>>>>>>>            return Halt_Status; >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> int main() >>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>            HHH(DD); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Try to convert it to TM language to know you know nothing. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I spent 22 years on this. I started with the Linz text >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>>>           or >>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩ >>>>>>>>>>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>>>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H >>>>>>>>>>>>>>> cannot possibly reach its simulated final halt state >>>>>>>>>>>>>>> ⟨Ĥ.qn⟩ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To refute the HP, you need to understand what it exactly >>>>>>>>>>>>>>>> means in TM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have known this for 22 years. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A working TM. Build it explicitly from transition >>>>>>>>>>>>>> function, then explain >>>>>>>>>>>>>> your derivation. You know nothing. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> That would be like examining how an operating system >>>>>>>>>>>>> works entirely from its machine code. >>>>>>>>>>>> >>>>>>>>>>>> You are refuting a CS foundamental theorem (i.e. HP) >>>>>>>>>>>> officially. >>>>>>>>>>>> So, yes, and actually MORE need to be done (beyond your >>>>>>>>>>>> imagination). >>>>>>>>>>>> >>>>>>>>>>>> Knowing a car or smart phone,... is far different from >>>>>>>>>>>> making one. >>>>>>>>>>>> Knowing E=mc^2 is far from knowing relativity, making A-bomb >>>>>>>>>>>> (actually, making >>>>>>>>>>>> A-bomb don't need to know E=mc^2, people are often fooled by >>>>>>>>>>>> popular saying) >>>>>>>>>>>> Every chapter of Linz's book, C text textbook has exercises, >>>>>>>>>>>> you need to those >>>>>>>>>>>> exercises AT LEAST to comment CS (and computation theory is >>>>>>>>>>>> more advanced topic >>>>>>>>>>>> than TM). Saying so is because we know you can't do the >>>>>>>>>>>> exercise and boast lots >>>>>>>>>>>> about TM stuff (and pretty much anything else from just >>>>>>>>>>>> reading words), even >>>>>>>>>>>> about theorem. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>         or >>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>> >>>>>>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩ >>>>>>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>>>> >>>>>>>>>>> All that I need to know is that I proved that >>>>>>>>>>> embedded_H correctly recognizes the repeating >>>>>>>>>>> pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>>>> cannot possibly reach its own simulated final >>>>>>>>>>> halt state of ⟨Ĥ.qn⟩ >>>>>>>>>>> >>>>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>> >>>>>>>>>>>>> We only have to actually know one detail: >>>>>>>>>>>>> Every counter-example input encoded in any model >>>>>>>>>>>>> of computation always specifies recursive simulation >>>>>>>>>>>>> that never halts to its corresponding simulating >>>>>>>>>>>>> termination analyzer. >>>>>>>>>>>> >>>>>>>>>>>> More example here that you don't understand nearly all CS >>>>>>>>>>>> terms. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Mere empty rhetoric entirely bereft of any supporting >>>>>>>>>>> reasoning. The x86 language is comparable to a RASP >>>>>>>>>>> machine that is equivalent to a Turing machine. >>>>>>>>>> >>>>>>>>>> Question: >>>>>>>>>> 1. Do you understand that you can't do the exercises in Linz's >>>>>>>>>> book? >>>>>>>>> >>>>>>>>> Everything is 100% irrelevant besides the fact that >>>>>>>>> I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by >>>>>>>>> embedded_H cannot possibly reach its own simulated >>>>>>>>> final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports >>>>>>>>> on the behavior that its input specifies it can >>>>>>>>> correctly transition to Ĥ.qn. >>>>>>>>> >>>>>>>>>> 2. Do you understand your ability of C/assembly/TM is less >>>>>>>>>> than 1 year CS level? >>>>>>>>>> >>>>>>>>> >>>>>>>>> I construe C as high level assembly language thus >>>>>>>>> disregard any inessentials. No change since K & R >>>>>>>>> is of any use to me. I write C++ the same way. I >>>>>>>>> use it as C with classes. I also use std::vector a lot. >>>>>>>> >>>>>>>> Q3. If people know the capability of the author of POOH is less >>>>>>>> than 1 year CS ========== REMAINDER OF ARTICLE TRUNCATED ==========