Deutsch   English   Français   Italiano  
<e4774b9cb5c12b70305d062800b4387d9a566722@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: The input to HHH(DDD) specifies a non-halting sequence of
 configurations +++
Date: Mon, 16 Jun 2025 21:52:26 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <e4774b9cb5c12b70305d062800b4387d9a566722@i2pn2.org>
References: <1025i6j$afk6$1@dont-email.me> <1025j6l$4nm5$1@dont-email.me>
 <1025jn5$aqju$1@dont-email.me> <1025kkk$4nm5$2@dont-email.me>
 <1025l2e$aqju$3@dont-email.me> <1025l7l$4nm5$3@dont-email.me>
 <1025n51$b964$2@dont-email.me> <1026d6e$g0hl$2@dont-email.me>
 <1026rvc$j3rp$3@dont-email.me>
 <bcf9f5c929d87513847a8bca27b31e184d447e84@i2pn2.org>
 <1027vah$r7bj$5@dont-email.me> <10295kr$17jfi$1@dont-email.me>
 <1029jnd$1ah2f$3@dont-email.me> <102be83$1s967$1@dont-email.me>
 <102c2bu$20jl4$4@dont-email.me> <102h0gt$3db1e$1@dont-email.me>
 <102jvnl$793t$6@dont-email.me> <102m3vn$quai$1@dont-email.me>
 <102mn5i$uef9$11@dont-email.me> <102p06t$1jvaf$1@dont-email.me>
 <102q145$1shmm$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 17 Jun 2025 02:14:08 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="825359"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <102q145$1shmm$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 6/16/25 5:08 PM, olcott wrote:
> On 6/16/2025 6:46 AM, Mikko wrote:
>> On 2025-06-15 15:00:02 +0000, olcott said:
>>
>>> On 6/15/2025 4:32 AM, Mikko wrote:
>>>> On 2025-06-14 14:07:49 +0000, olcott said:
>>>>
>>>>> On 6/13/2025 6:02 AM, Mikko wrote:
>>>>>> On 2025-06-11 14:03:41 +0000, olcott said:
>>>>>>
>>>>>>> On 6/11/2025 3:20 AM, Mikko wrote:
>>>>>>>> On 2025-06-10 15:41:33 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 6/10/2025 6:41 AM, Mikko wrote:
>>>>>>>>>> On 2025-06-10 00:47:12 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 6/9/2025 7:26 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/9/25 10:43 AM, olcott wrote:
>>>>>>>>>>>>> On 6/9/2025 5:31 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>> Op 09.jun.2025 om 06:15 schreef olcott:
>>>>>>>>>>>>>>> On 6/8/2025 10:42 PM, dbush wrote:
>>>>>>>>>>>>>>>> On 6/8/2025 11:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/8/2025 10:32 PM, dbush wrote:
>>>>>>>>>>>>>>>>>> On 6/8/2025 11:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 6/8/2025 10:08 PM, dbush wrote:
>>>>>>>>>>>>>>>>>>>> On 6/8/2025 10:50 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>    HHH(DDD);
>>>>>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The *input* to simulating termination analyzer 
>>>>>>>>>>>>>>>>>>>>> HHH(DDD)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No it's not, as halt deciders / termination 
>>>>>>>>>>>>>>>>>>>> analyzers work with algorithms,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That is stupidly counter-factual.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That you think that shows that
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My understanding is deeper than yours.
>>>>>>>>>>>>>>>>> No decider ever takes any algorithm as its input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But they take a description/specification of an algorithm,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There you go.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> which is what is meant in this context.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It turns out that this detail makes a big difference.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And because your HHH does not work with the description/ 
>>>>>>>>>>>>>>>> specification of an algorithm, by your own admission, 
>>>>>>>>>>>>>>>> you're not working on the halting problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HHH(DDD) takes a finite string of x86 instructions
>>>>>>>>>>>>>>> that specify that HHH simulates itself simulating DDD.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And HHH fails to see the specification of the x86 
>>>>>>>>>>>>>> instructions. It aborts before it can see how the program 
>>>>>>>>>>>>>> ends.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is merely a lack of sufficient technical competence
>>>>>>>>>>>>> on your part. It is a verified fact that unless the outer
>>>>>>>>>>>>> HHH aborts its simulation of DDD that DDD simulated by HHH
>>>>>>>>>>>>> the directly executed DDD() and the directly executed HHH()
>>>>>>>>>>>>> would never stop running. That you cannot directly see this
>>>>>>>>>>>>> is merely your own lack of sufficient technical competence.
>>>>>>>>>>>>
>>>>>>>>>>>> And it is a verified fact that you just ignore that if HHH 
>>>>>>>>>>>> does in fact abort its simulation of DDD and return 0, then 
>>>>>>>>>>>> the behavior of the input, PER THE ACTUAL DEFINITIONS, is to 
>>>>>>>>>>>> Halt, and thus HHH is just incorrect.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void DDD()
>>>>>>>>>>> {
>>>>>>>>>>>    HHH(DDD);
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> How the f-ck does DDD correctly simulated by HHH
>>>>>>>>>>> reach its own "return" statement final halt state?
>>>>>>>>>>
>>>>>>>>>> If HHH is not a decider the question is not interesting.
>>>>>>>>>
>>>>>>>>> I switched to the term: "termination analyzer" because halt 
>>>>>>>>> deciders
>>>>>>>>> have the impossible task of being all knowing.
>>>>>>>>
>>>>>>>> The termination problem is in certain sense harder than the halting
>>>>>>>> problem.
>>>>>>>
>>>>>>> Not at all
>>>>>>
>>>>>> That's in another sense in which nothing is harder than impossible.
>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>>    HHH(DDD);
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> If HHH only determines non-halting correctly for the
>>>>>>> above input and gets the wrong answer on everything
>>>>>>> else then HHH *is* a correct termination analyzer.
>>>>>>
>>>>>> It is not a correct termination analyzer if if gives the wrong 
>>>>>> answer.
>>>>>
>>>>> *Key verified facts such that disagreement is inherently incorrect*
>>>>>
>>>>> (a) HHH(DDD) does not correctly report on the behavior of its caller.
>>>>
>>>> True.
>>>>
>>>>> (b) Within the theory of computation HHH is not allowed to report
>>>>>      on the behavior of its caller.
>>>>
>>>> False. The theory of computation does not prohibit anything.
>>>
>>> *Sure it does*
>>> A termination analyzer / partial halt decider is required
>>> to report on the sequence of state transitions that its
>>> input specifies. It is not allowed to report on anything else.
>>
>> The word "partial" means that it is not required to report.
>> But if it does report it is required to report correctly whether
>> the computation described by the input halts if fully executed.
>> An incorret report is not allowed but a lack of report is.
>>
> 
> Its input could be described as performing some
> arbitrary unspecified sequence of steps, thus
> "described" is an insufficiently precise term.

Nope, because that would not be a CORRECT represention of the program.

Of course, since

> 
> To correct that error I say that the termination
> analyzer must report on the behavior specified
> by the sequence of steps of its input.

WHich since the input isn't a "sequence of steps" is just a category error.

It is some precise representation/desciption/specification that gives 
the algorithm of the program it is talking about, allowing the 
recreation of the steps, WHEN COMPLETELY RUN/SIMULTED.

Since HHH stops, the steps it sees are not the full "behavior of the input"

> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> When one or more instructions of DDD are correctly
> simulated by ANY simulating termination analyzer HHH
> then this correctly simulated DDD never reaches its
========== REMAINDER OF ARTICLE TRUNCATED ==========