| Deutsch English Français Italiano |
|
<vvrk67$o2ab$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Sun, 11 May 2025 20:51:03 -0500 Organization: A noiseless patient Spider Lines: 95 Message-ID: <vvrk67$o2ab$2@dont-email.me> References: <vv97ft$3fg66$1@dont-email.me> <853816e160c7b3fe75c71f0728e72989d9fb2e41.camel@gmail.com> <vvp1fm$3r5li$4@dont-email.me> <b049926b61baa5d69d11655a8af06e537b7acd71.camel@gmail.com> <vvqga9$gldn$3@dont-email.me> <41e08841caf0d628beb5105bc78531a412eea440.camel@gmail.com> <vvql3p$gldn$15@dont-email.me> <cb999b6746607a1445c196e485a2c1124eaee8b5.camel@gmail.com> <vvqnev$i5d0$3@dont-email.me> <07c4f2302645a7e58957b5e5bffed80397a6ddae.camel@gmail.com> <vvr0ot$k9nu$1@dont-email.me> <04bd32e2a5572305de0376f9569172932ffb252f.camel@gmail.com> <vvr2ov$khl4$2@dont-email.me> <72f8c8295d3a0ff265a67b0de838516ade16c6d5.camel@gmail.com> <vvr6lj$lieg$1@dont-email.me> <8667c45172be6519444525c30d280cde06d77e2b.camel@gmail.com> <vvr8dj$lu2b$1@dont-email.me> <7281f97665272ea0eb85e56940648f6c807b0b8e.camel@gmail.com> <vvralq$me5h$1@dont-email.me> <f5a9ca0c0edaeb582b14c3babee27e25d41fc953.camel@gmail.com> <vvrgmf$n9a9$4@dont-email.me> <d3eedafd84b780cdb0bd63c8afd0aa92209136ab@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 12 May 2025 03:51:04 +0200 (CEST) Injection-Info: dont-email.me; posting-host="15cac720ddbb61c7f6586fe023932af8"; logging-data="788811"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19jdR0Ry6//MKjgiLAaSzrs" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:5K5P0v8dx2yjybeLq3ccqnp6Gsw= X-Antivirus: Norton (VPS 250511-4, 5/11/2025), Outbound message X-Antivirus-Status: Clean Content-Language: en-US In-Reply-To: <d3eedafd84b780cdb0bd63c8afd0aa92209136ab@i2pn2.org> On 5/11/2025 8:15 PM, Richard Damon wrote: > On 5/11/25 8:51 PM, olcott wrote: >> On 5/11/2025 7:33 PM, wij wrote: >>> On Sun, 2025-05-11 at 18:08 -0500, olcott wrote: >>>> On 5/11/2025 5:50 PM, wij wrote: >>>>> On Sun, 2025-05-11 at 17:30 -0500, olcott wrote: >>>>>> On 5/11/2025 5:11 PM, wij wrote: >>>>>>> On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: >>>>>>> [cut] >>>>>>>>>> ZFC corrected the error in set theory so that >>>>>>>>>> it could resolve Russell's Paradox. The original >>>>>>>>>> set theory has now called naive set theory. >>>>>>>>>> >>>>>>>>>> I corrected the error of the HP that expects >>>>>>>>>> HHH to report on behavior that is different >>>>>>>>>> than the behavior that its input actually >>>>>>>>>> specifies. >>>>>>>>> >>>>>>>>> Specificly, "Halt(D)=1 iff D() halts" is an error? >>>>>>>>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>>>>>>>> >>>>>>>> >>>>>>>> Yes that is an error because the behavior that >>>>>>>> the input to HHH(DDD) specifies is the behavior >>>>>>>> that HHH must report on. >>>>>>> >>>>>>> If so, how do we know a given function e.g. D, halts or not by >>>>>>> giving it to H, >>>>>>> i.e. H(D)? Wrong question (according to you)? >>>>>> >>>>>> H and D is too vague and ambiguous. >>>>>> We know that the input to HHH(DDD) specifies >>>>>> a non-halting sequence of configurations. >>>>>> >>>>>> We know that the input to HHH1(DDD) specifies >>>>>> a halting sequence of configurations. >>>>>> >>>>>>> Instead, every time we want to know whether D halts or not, >>>>>> >>>>>> When we intentionally define an input to attempt >>>>>> to thwart a specific termination analyzer THIS DOES >>>>>> CHANGE THE BEHAVIOR. >>>>>> >>>>>> If we let people run uploaded programs on our >>>>>> network we need to know if these programs are >>>>>> going to halt. >>>>>> >>>>>> Unless HHH(DDD) rejects its input as non-halting >>>>>> HHH will continue to eat up network resources. >>>>> >>>>> But, according to POOH, if D going to eat up network resources, it >>>>> have to >>>>> happen when we run POOH(D), because you said D's halting property only >>>>> valid to H. >>>>> >>>> >>>> If we want to prevent this kind of denial of service >>>> attack HHH must be able correctly handle inputs that >>>> are trying to thwart it or HHH fails. >>>> >>>> When HHH is our official denial of service attack >>>> preventer it either rejects its input DDD as non >>>> halting or it gets stuck in recursive emulation >>>> thus fails. >>>> >>>> It always has been the requirement that a termination >>>> analyzer was required to report on the behavior that >>>> its input actually specifies. >>>> >>>> This is a subtle nuance of functions computed by >>>> models of computation that no one bothered to >>>> pay attention to because they didn't know it made >>>> any difference. >>>> >>> >>> Is DDD a virus? >>> >> >> If on a real system an input tried to fool the >> denial-of-service-attack detector IT WOULD FAIL. >> >> Prior to my work a denial-of-service-attack detector >> WOULD FAIL. It would not know to reject DDD. >> > > But DDD doesn't do a denial of service, so it is a false positive. > When HHH is a denial-of-service-detector and DDD is trying to fool HHH into getting stuck in recursive emulation thus causing denial-of-service HHH is not fooled. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer