Deutsch   English   Français   Italiano  
<vvrkfp$mv2a$6@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: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sun, 11 May 2025 21:56:10 -0400
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <vvrkfp$mv2a$6@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <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>
 <vvrk67$o2ab$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 12 May 2025 03:56:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d587ba6f088c47ed8fd2ad250ebfd646";
	logging-data="752714"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18CfBMrWR7wicV3lZS5eSfr"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:wrFcmygpYnsJH2GwDy07FPc2kQs=
Content-Language: en-US
In-Reply-To: <vvrk67$o2ab$2@dont-email.me>

On 5/11/2025 9:51 PM, olcott wrote:
> 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 

Then it is not a halt decider / termination analyzer, and therefore 
irrelevant to the halting problem.