Deutsch English Français Italiano |
<e614d6b981fd5fa6eefc84894a14448d4663e3c7@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon <richard@damon-family.org> Newsgroups: comp.theory Subject: Re: HHH maps its input to the behavior specified by it --- key error in all the proofs Date: Mon, 12 Aug 2024 11:05:36 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <e614d6b981fd5fa6eefc84894a14448d4663e3c7@i2pn2.org> References: <v8jh7m$30k55$1@dont-email.me> <v98hpa$t1hv$1@dont-email.me> <2fee2a47a11178b8ec9089878a51aa7ccb410fc2@i2pn2.org> <v98j19$taas$1@dont-email.me> <e594b5b47303846026e79ab95d1ba6b528ba6267@i2pn2.org> <v98leq$tna8$1@dont-email.me> <f2715e52691fec808c2ae5953e65fb42f4e19fa9@i2pn2.org> <v98mj9$tunr$1@dont-email.me> <86cbe5924d3495f56986483f79567af3e6efde8a@i2pn2.org> <v98qbj$ul50$1@dont-email.me> <49e9799be11c5e626bc05a421227bb7563982f0d@i2pn2.org> <v98uf7$vepo$1@dont-email.me> <60f1a533219c1237071f358999228eb48727f5e9@i2pn2.org> <v991tu$vepo$2@dont-email.me> <895f5e9b934bbfb72925fb109043500d49100a6a@i2pn2.org> <v994vs$10cfm$1@dont-email.me> <dec62801011bc5bf0b9eb9a62c607cf407198609@i2pn2.org> <v99870$14mlk$1@dont-email.me> <0f8f134fe961ee00910cce1d7f05b632d7567c6c@i2pn2.org> <v9abfu$2nabt$1@dont-email.me> <86c21e8a63450bf8b0c32f4f17ba0b503a914fe0@i2pn2.org> <v9d01i$39tbd$2@dont-email.me> <2c853efb65c3d8e2d4ba1c484f7002c74c68d895@i2pn2.org> <v9d1v8$3a9pe$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 12 Aug 2024 15:05:37 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2312776"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird In-Reply-To: <v9d1v8$3a9pe$1@dont-email.me> X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US Bytes: 17357 Lines: 337 On 8/12/24 9:16 AM, olcott wrote: > On 8/12/2024 8:04 AM, Richard Damon wrote: >> On 8/12/24 8:43 AM, olcott wrote: >>> On 8/11/2024 12:06 PM, Richard Damon wrote: >>>> On 8/11/24 8:40 AM, olcott wrote: >>>>> On 8/11/2024 6:08 AM, Richard Damon wrote: >>>>>> On 8/10/24 10:38 PM, olcott wrote: >>>>>>> On 8/10/2024 9:21 PM, Richard Damon wrote: >>>>>>>> On 8/10/24 9:43 PM, olcott wrote: >>>>>>>>> On 8/10/2024 8:13 PM, Richard Damon wrote: >>>>>>>>>> On 8/10/24 8:51 PM, olcott wrote: >>>>>>>>>>> On 8/10/2024 7:20 PM, Richard Damon wrote: >>>>>>>>>>>> On 8/10/24 7:52 PM, olcott wrote: >>>>>>>>>>>>> On 8/10/2024 5:47 PM, Richard Damon wrote: >>>>>>>>>>>>>> On 8/10/24 6:41 PM, olcott wrote: >>>>>>>>>>>>>>> On 8/10/2024 4:53 PM, Richard Damon wrote: >>>>>>>>>>>>>>>> On 8/10/24 5:37 PM, olcott wrote: >>>>>>>>>>>>>>>>> On 8/10/2024 4:33 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 8/10/24 5:18 PM, olcott wrote: >>>>>>>>>>>>>>>>>>> On 8/10/2024 3:58 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 8/10/24 4:36 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> As I have countlessly proven it only requires >>>>>>>>>>>>>>>>>>>>> enough correctly >>>>>>>>>>>>>>>>>>>>> emulated steps to correctly infer that the input >>>>>>>>>>>>>>>>>>>>> would never >>>>>>>>>>>>>>>>>>>>> reach is "return" instruction halt state. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Except that HHH does't do that, since if HHH decides >>>>>>>>>>>>>>>>>>>> to abort and return, then the DDD that it is >>>>>>>>>>>>>>>>>>>> emulating WILL return, just after HHH has stopped >>>>>>>>>>>>>>>>>>>> its emulation. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> You just confuse the behavior of DDD with the >>>>>>>>>>>>>>>>>>>> PARTIAL emulation that HHH does, because you lie >>>>>>>>>>>>>>>>>>>> about your false "tautology". >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Denying a tautology seems to make you a liar. I only >>>>>>>>>>>>>>>>>>>>> say "seems to" because I know that I am fallible. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Claiming a false statement is a tautology only make >>>>>>>>>>>>>>>>>>>> you a liar. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In this case, you lie is that the HHH that you are >>>>>>>>>>>>>>>>>>>> talking about do the "correct emulation" you base >>>>>>>>>>>>>>>>>>>> you claim on. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> That is just a deception like the devil uses, has >>>>>>>>>>>>>>>>>>>> just a hint of truth, but the core is a lie. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> What I say is provably correct on the basis of the >>>>>>>>>>>>>>>>>>> semantics of the x86 language. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Nope. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The x86 language says DDD will Halt if HHH(DDD) >>>>>>>>>>>>>>>>>> returns a value. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> HHH is called by main() there is no directly executed >>>>>>>>>>>>>>>>> DDD() >>>>>>>>>>>>>>>>> any where in the whole computation. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Except in your requirements, and we can see what it does >>>>>>>>>>>>>>>> by adding a call to DDD from main, since nothing in your >>>>>>>>>>>>>>>> system calls main. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> All that you need to know is that there is not any >>>>>>>>>>>>>>> directly executed DDD() anywhere in the computation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But there ccould be, and the behavior of it is what matters. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The key error of the halting problem proofs all of these >>>>>>>>>>>>> years has been the false assumption that a halt decider >>>>>>>>>>>>> must report on the behavior of the computation that itself >>>>>>>>>>>>> is contained within. >>>>>>>>>>>> >>>>>>>>>>>> But it isn't a false assemption, but an actual requirement. >>>>>>>>>>>> >>>>>>>>>>>> A Halt Decider must be able to correctly answer for ANY >>>>>>>>>>>> Turing Machine represented as its input. >>>>>>>>>>>> >>>>>>>>>>>> ANY includes those that are built from a copy of itself. >>>>>>>>>>>> >>>>>>>>>>>> So, a Halt Decider needs to be able to correctly answer >>>>>>>>>>>> about programs that include copies of itself, even with >>>>>>>>>>>> contrary behavior, which is what makes it impossible to >>>>>>>>>>>> compute. >>>>>>>>>>>> >>>>>>>>>>>> You seem to confuse non-computable with invalid, it seems in >>>>>>>>>>>> part because you don't understand the difference between >>>>>>>>>>>> knowledge and truth. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Everyone has simply assumed that the behavior of the >>>>>>>>>>>>> input to a decider must exactly match the direct execution >>>>>>>>>>>>> of this input. They only did this because everyone rejected >>>>>>>>>>>>> simulation out-of-hand without review. >>>>>>>>>>>> >>>>>>>>>>>> Because that is the DEFINITION of what it is to decide on. >>>>>>>>>>>> >>>>>>>>>>>> You just don't understand what a requirement is. >>>>>>>>>>>> >>>>>>>>>>>> Since the DEFINITION of "Correct Simulation" that you are >>>>>>>>>>>> trying to use (from a UTM) means a machine the EXACTLY >>>>>>>>>>>> reproduces the behavior of the direct exectution of the >>>>>>>>>>>> machine described by the input, the correct simulation must >>>>>>>>>>>> exactly match the behavior of the direct execution. >>>>>>>>>>>> >>>>>>>>>>>> You can't get out of it by trying to lie about it being >>>>>>>>>>>> different. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This caused them to never notice that the input simulated >>>>>>>>>>>>> according to its correct semantics does call its own decider >>>>>>>>>>>>> in recursive simulation thus cannot possibly return to its >>>>>>>>>>>>> caller. The Linz proof is sufficiently isomorphic so this >>>>>>>>>>>>> equally >>>>>>>>>>>>> applies to the Linz TM proof. >>>>>>>>>>>> >>>>>>>>>>>> Nope, just shows you don't know what "Correct" means. >>>>>>>>>>>> >>>>>>>>>>>> Your proof is NOT "sufficiently isomorphic" since by your >>>>>>>>>>>> own claims it is clearly not even Turing Complete, so no >>>>>>>>>>>> where near isomorphic. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If HHH were to report on the direct execution of DDD it would >>>>>>>>>>>>> be breaking the definition of a halt decider that only >>>>>>>>>>>>> computes >>>>>>>>>>>>> the mapping from its input... >>>>>>>>>>>> >>>>>>>>>>>> Nope. Since the mapping that it is supposed to compute is >>>>>>>>>>>> DEFINED as based on the direct exectut >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No it never has been this. I has always been a mapping >>>>>>>>>>> from the behavior that the finite string specifies. It >>>>>>>>>>> has never been the behavior of the actual computation >>>>>>>>>>> that the decider is contained within. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> And thatg behavior is specified to be the behavior of the >>>>>>>>>> program the input represents. PERIOD. >>>>>>>>>> >>>>>>>>> >>>>>>>>> That has never been true. It is always the case that every >>>>>>>>> decider of any kind only computes the mapping from its input >>>>>>>>> finite string and never gives a rat's ass about anything else >>>>>>>>> anywhere else. ========== REMAINDER OF ARTICLE TRUNCATED ==========