Path: ...!weretis.net!feeder9.news.weretis.net!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 --- Complete Closure
Date: Tue, 13 May 2025 07:33:22 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <49c3931c53cdb00b9ab4b2f5e0511ddf1730d058@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>
 <16cab64f3d5b4a5d1533d38030f611d262eeb055@i2pn2.org>
 <vvujr1$1j6s0$4@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 11:47:27 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="172461"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vvujr1$1j6s0$4@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 8195
Lines: 168

On 5/13/25 1:03 AM, olcott wrote:
> On 5/12/2025 11:02 PM, Richard Damon wrote:
>> 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.
>>
> 
> 
> You don't seem to get tautologies so you
> probably won't get this one.

To BE a Tautology, they need to be true.

> 
> All termination analyzers are correct (on this one input)
> when they correctly determine the halt state of one input
> with no inputs.

But they do need to be correct, and correct halt state is based on the 
RUNNING OF THE PROGRAM.



> 
> On the other hand a halt decider that gets one
> input incorrectly is not a decider at all.

And so is a Termination Analyser. Getting one answer correct means (as 
yoiu said) correct for that one, it does not mean you are "a correct" 
analyzer.

I guess you thought you were smart because you got one answer right on 
your intelgence test, even though you missed all the others.

You can't say you are law abiding just because you didn't kill your 
mother (but did your father).

Sorry, "Correct" meas universally correct, not just in a single 
instance. You are just demonstrating your lack of understanding of the 
language you are using.

> 
>>>
>>> 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.
>>
> 
> That is not the way that reality actually works.

Sure it is, you got a relaible source that says otherwise?

It seems YOU are the one that has problems with reality.

> 
>>>
>>> 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.
>>
> 
> The input to HHH(DD) specifies recursive emulation.
> The exact same string of machine code bytes as input
> to HHH1(DD) does not specify recursive emulation.

Because the limited string you quote doesn't actually specify either, 
but just a string of bytes that doesn't have meaning without more context.

> 
> We probably should stay with the one point until we
> have complete closure.
> 

I suppose we need to find a point that you are acually correct at to 
work from.

I am not sure what point that would be. I think I have shown errors in 
just about everything you have said, and you misinterprete even the few 
things you say corretly to means something they don't.

Go ahead, try to find the point you said correctly.

Remember, you are working under the definition of the Field of 
Computation Theory, not your POOPS, so statements will be interpreted by 
that,
========== REMAINDER OF ARTICLE TRUNCATED ==========