Path: ...!eternal-september.org!feeder3.eternal-september.org!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 12:00:41 -0500 Organization: A noiseless patient Spider Lines: 133 Message-ID: References: <088556c03067d8de7184bf88dd01cc6b8c99ba1b.camel@gmail.com> <09cea75db07408dc9203aca3fb74408ad3a095b4.camel@gmail.com> <853816e160c7b3fe75c71f0728e72989d9fb2e41.camel@gmail.com> <41e08841caf0d628beb5105bc78531a412eea440.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 19:00:41 +0200 (CEST) Injection-Info: dont-email.me; posting-host="ef7faca461217fa132b1f53eef89d0be"; logging-data="546231"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18BEtKJ3iym2jE3xs9i+qJF" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:QufRbRQgZKVKdt2dnALCEptzPd8= X-Antivirus: Norton (VPS 250511-4, 5/11/2025), Outbound message Content-Language: en-US In-Reply-To: <41e08841caf0d628beb5105bc78531a412eea440.camel@gmail.com> X-Antivirus-Status: Clean Bytes: 7102 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. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer