Deutsch English Français Italiano |
<v99870$14mlk$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory Subject: Re: HHH maps its input to the behavior specified by it --- key error in all the proofs Date: Sat, 10 Aug 2024 21:38:23 -0500 Organization: A noiseless patient Spider Lines: 268 Message-ID: <v99870$14mlk$1@dont-email.me> References: <v8jh7m$30k55$1@dont-email.me> <v98ag9$rj63$1@dont-email.me> <9721b1bcc4a6849dabc5d7956754292823381840@i2pn2.org> <v98e8s$sddi$2@dont-email.me> <f7a568982428ce74da1635a0537c47580063d45b@i2pn2.org> <v98g9c$sres$1@dont-email.me> <5586bed1ae799730f4f5cda602007aa0a67a5b71@i2pn2.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 11 Aug 2024 04:38:24 +0200 (CEST) Injection-Info: dont-email.me; posting-host="2823e9f63915b861ed765b8be41520b0"; logging-data="1202868"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0sD64SMctS5WqPEGIr1T1" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:2fGxiOFvAxpLd0pfz3/yTaMCiVo= Content-Language: en-US In-Reply-To: <dec62801011bc5bf0b9eb9a62c607cf407198609@i2pn2.org> Bytes: 13675 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. > > No, you are confusing capability with requirements. > > A "Foo Decider" has ALWAYS been required to compute the "Foo" mapping, > as that mapping is defined. > > The "Halting" mapping is defined as the behavior of the machine/input > represented by the input, so the input needs to be a representation of > the program and input and the decider tries to compute the mapping of > that representation to the behavior that program represents. > > How that isn't the "mapping" of the input to a Halt Decider seems to put > a big hole in your argument. > > So, the behavior of the program the input describes *IS* the mapping > that HHH needs to try to compute to be a halt decider, as that is the > mapping that Halting defines. > ========== REMAINDER OF ARTICLE TRUNCATED ==========