Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: How the requirements that Professor Sipser agreed to are exactly
 met
Date: Mon, 12 May 2025 23:31:59 -0400
Organization: A noiseless patient Spider
Lines: 159
Message-ID: <vvueff$1c062$12@dont-email.me>
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 05:31:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="525f3751cca56668838a1ae1f1e0ddfb";
	logging-data="1441986"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/VYBQpvNy/CUM0j2sXbwfG"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:sGzIpvtt2SWD1BjcTuR1IwySENg=
In-Reply-To: <vvudtm$1ibhq$1@dont-email.me>
Content-Language: en-US

On 5/12/2025 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.

False, as a universal termination analyzer must still answer for all 
algorithms the following mapping:


Given any algorithm (i.e. a fixed immutable sequence of instructions) X 
described as <X> with input Y:

A solution to the halting problem is an algorithm H that computes the 
following mapping:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly


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

False, because it specifies the description of an algorithm that halts 
when executed directly.

> 
> HHH(DD) does not compute the mapping from its input
> to BEHAVIOR THAT THIS INPUT DOES NOT SPECIFY.
> 
> 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.

That's because if I want to know if any arbitrary algorithm X with input 
Y will halt when executed directly, that requires an H that meets these 
requirements, not your alternate requirements:


Given any algorithm (i.e. a fixed immutable sequence of instructions) X 
described as <X> with input Y:

A solution to the halting problem is an algorithm H that computes the 
following mapping:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly

> 
> 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.
> 

A LIE, as you were given numerous reasons below why this mapping is 
useful and your alternate mapping is not useful, and your failure to 
respond to this constitutes your acceptance of this fact.


On 5/12/2025 10:22 PM, dbush wrote:
 > On 5/12/2025 10:01 PM, olcott wrote:
 >> If the Goldbach conjecture is true (and there is
 >> no short-cut) this requires testing against every
 >> element of the set of natural numbers an infinite
 >> computation.
 >
 > And if we take that computation and feed it into an H that meets these
 > requirements:
 >
 >
 > Given any algorithm (i.e. a fixed immutable sequence of instructions) X
 > described as <X> with input Y:
 >
 > A solution to the halting problem is an algorithm H that computes the
 > following mapping:
 >
 > (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
 > (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed 
directly
 >
 >
 > Then if H reports non-halting the Goldbach conjecture is true, and if H
 > reports halting the Goldbach conjecture is false.
 >
 > If on the other hand we feed the computation to an H that tells us if it
 > "specifies non-halting behavior to H", we won't necessarily get that
 > answer.  We have to worry about how the computation is implemented. With
 > the above requirements we don't need to worry about that.
 >
 > The same applies to *any* process which may or may not be infinite to
 > tell us whether or not it is actually an infinite process.