Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Sun, 11 May 2025 17:00:19 -0500 Organization: A noiseless patient Spider Lines: 200 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: Mon, 12 May 2025 00:00:20 +0200 (CEST) Injection-Info: dont-email.me; posting-host="15cac720ddbb61c7f6586fe023932af8"; logging-data="707024"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+rbgUO2ILXIDf2AUkVsqK" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:csT5eHZoE8H/61yXR8oQBvBDF4Q= In-Reply-To: <72f8c8295d3a0ff265a67b0de838516ade16c6d5.camel@gmail.com> X-Antivirus: Norton (VPS 250511-4, 5/11/2025), Outbound message Content-Language: en-US X-Antivirus-Status: Clean 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 >>>>>>>        level. How persuasive and reliable of POOH do you think it would be? >>>>>>> >>>>>>> Q4: Why no one can reproduce the result of POOH for these 22? years? >>>>>>> >>>>>>> >>>>>> >>>>>> _DDD() >>>>>> [00002172] 55         push ebp      ; housekeeping >>>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping >>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>> [0000217f] 83c404     add  esp,+04 >>>>>> [00002182] 5d         pop  ebp >>>>>> [00002183] c3         ret >>>>>> Size in bytes:(0018) [00002183] ========== REMAINDER OF ARTICLE TRUNCATED ==========