Deutsch   English   Français   Italiano  
<16cab64f3d5b4a5d1533d38030f611d262eeb055@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: How the requirements that Professor Sipser agreed to are exactly
 met
Date: Tue, 13 May 2025 00:02:27 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <16cab64f3d5b4a5d1533d38030f611d262eeb055@i2pn2.org>
References: <vvte01$14pca$29@dont-email.me> <vvte62$15ceh$18@dont-email.me>
 <vvtej1$181kg$1@dont-email.me> <vvtjj8$15ceh$19@dont-email.me>
 <vvtl1g$19cvp$1@dont-email.me> <vvtlmm$15ceh$20@dont-email.me>
 <vvto7c$1a1pf$1@dont-email.me> <vvtpqu$1agqu$1@dont-email.me>
 <vvtq8d$1a1pf$2@dont-email.me> <vvtqn1$1agqu$2@dont-email.me>
 <vvtsmf$1aube$1@dont-email.me> <vvtsq5$1agqu$3@dont-email.me>
 <vvttf7$1bfib$1@dont-email.me> <vvu008$1c062$1@dont-email.me>
 <vvu0mm$1c0vi$1@dont-email.me> <vvu0si$1c062$2@dont-email.me>
 <vvu1m8$1c86j$1@dont-email.me> <vvu2q2$1c062$3@dont-email.me>
 <vvu3ht$1c86j$3@dont-email.me> <vvu3lm$1c062$5@dont-email.me>
 <vvu42d$1cmbo$1@dont-email.me> <vvu46e$1c062$6@dont-email.me>
 <vvu5ch$1csst$1@dont-email.me> <vvu5j3$1c062$7@dont-email.me>
 <vvubqa$1deu5$3@dont-email.me> <vvuch8$1c062$11@dont-email.me>
 <vvudtm$1ibhq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 13 May 2025 04:26:04 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="127709"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vvudtm$1ibhq$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US

On 5/12/25 11:22 PM, olcott wrote:
> On 5/12/2025 9:58 PM, dbush wrote:
>> On 5/12/2025 10:46 PM, olcott wrote:
>>> On 5/12/2025 8:00 PM, dbush wrote:
>>>> On 5/12/2025 8:56 PM, olcott wrote:
>>>>> On 5/12/2025 7:36 PM, dbush wrote:
>>>>>> On 5/12/2025 8:34 PM, olcott wrote:
>>>>>>> On 5/12/2025 7:27 PM, dbush wrote:
>>>>>>>> On 5/12/2025 8:25 PM, olcott wrote:
>>>>>>>>> On 5/12/2025 7:12 PM, dbush wrote:
>>>>>>>>>> On 5/12/2025 7:53 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> Simulating Termination analyzers cannot possibly report
>>>>>>>>>>> on the actual behavior of non-terminating inputs
>>>>>>>>>>> because this would cause themselves to never terminate.
>>>>>>>>>>>
>>>>>>>>>>> They must always hypothesize what the behavior of the
>>>>>>>>>>> input would be if they themselves never aborted.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> False.  They must always hypothesize what the behavior of 
>>>>>>>>>> algorithm described by the input would be if it was executed 
>>>>>>>>>> directly, as per the requirements:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Show the actual reasoning of how it makes sense
>>>>>>>>> that a simulating termination analyzer should
>>>>>>>>> ignore the behavior (to its own peril) that the
>>>>>>>>> input actually specifies.
>>>>>>>>
>>>>>>>> There is no requirement that building a termination analyzer, 
>>>>>>>> simulating or otherwise, is possible.  In fact, it has proved to 
>>>>>>>> not be possible by Linz and others, which you have *explicitly* 
>>>>>>>> agreed with.
>>>>>>>>
>>>>>>>
>>>>>>> In other words you have no such actual reasoning.
>>>>>>
>>>>>> The reasoning is that there is no requirement that building a 
>>>>>> termination analyzer is possible. 
>>>>>
>>>>> So you have no actual reasoning that addresses my
>>>>> actual point.
>>>>>
>>>>>  >>>> Show the actual reasoning of how it makes sense
>>>>>  >>>> that a simulating termination analyzer should
>>>>>  >>>> ignore the behavior (to its own peril) that the
>>>>>  >>>> input actually specifies.
>>>>>
>>>>
>>>> It makes sense because that's what's required to tell me if any 
>>>> arbitrary algorithm X with input Y will halt when executed directly.
>>>>
>>>
>>> A simulating termination analyzer(STA) reports on
>>> the behavior of the direct execution of the
>>> algorithm specified by its input except in the
>>> case where the input calls this STA to try to fool it.
>>>
>>> What you are proposing would cause HHH to get stuck
>>> in infinite execution. How is getting stuck in
>>> infinite execution better than not getting stuck?
>>
>> In other words, if you assume that a termination analyzer exists, 
> 
> Unlike a halt decider that is either ALL KNOWING
> or wrong a termination analyzer is correct even
> if it can only compute the mapping from a single
> input (that has no inputs) to the behavior that
> this input specifies and thus its halt status.

Where od you get this from?

Just like Halt Deciders, a Complete Termination Analyser needs to 
correctly answer for all input.

> 
> HHH(DD) does correctly compute the mapping from its
> input to the behavior that this input specifies.

Nope, since DD Halts when run, and that is the DEFINITION of the 
behavior the input sepecifies.

> 
> HHH(DD) does not compute the mapping from its input
> to BEHAVIOR THAT THIS INPUT DOES NOT SPECIFY.

No, you are claiming that it should, since the behavior it specifies is 
the objective criteria of what the program it represents does when run, 
which is halting.

You are advocating that HHH soulud be computing the INCORRECT mapping of 
the subjective behavior of the partial emalation done by HHH, or the 
emulation of an input that it wasn't even given, since the input DD uses 
the one and only HHH in memory with it that aborts its emulation and 
returns 0.

> 
> The whole issue is that everyone here has been
> indoctrinated into baselessly believing that
> HHH should in some cases compute the mapping
> to BEHAVIOR THAT THE INPUT DOES NOT SPECIFY.

No, that is your position, because you have chosen to just ignore the 
definitoins, and stupidly presume you can look at some input that 
doesn't match the problem given.

For the Halting Problem, or the Termination analysis problem, the 
"behavior of the input" is *DEFINED* to be the behavior of the program 
the input represent when run.

Note, this also means that the input does need to be the representation 
of a program, which means it needs to include all the code used by it 
(and everything it calls), something you try your hardest to ignore.
> 
> No one can possibly provide any correct reasoning
> why HHH must do this because no such correct
> reasoning exists. On this issue it is merely
> THAT IS NOT THE WAY THAT I MEMORIZED IT.
> 

Like, it is the DEFINITION?

of course, that is something too esoteric for you to understand, you 
think we must lie about what we are doing, since that is all you know 
how to do.