Path: ...!news.misty.com!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: Turing Machine computable functions apply finite string
 transformations to inputs VERIFIED FACT
Date: Wed, 30 Apr 2025 19:27:25 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <648f40b21a6ba1b7233cd77eacf9efb5e9cd66eb@i2pn2.org>
References: <vu6lnf$39fls$2@dont-email.me> <vuj55m$2lf64$10@dont-email.me>
 <vuj8h3$2uahf$3@dont-email.me> <vujfuu$35hcg$1@dont-email.me>
 <65dddfad4c862e6593392eaf27876759b1ed0e69@i2pn2.org>
 <vujlj0$3a526$1@dont-email.me> <vujln7$32om9$8@dont-email.me>
 <vujmmm$3a526$2@dont-email.me> <vujmrj$32om9$9@dont-email.me>
 <vujtcb$3gsgr$1@dont-email.me> <vuju44$3hnda$1@dont-email.me>
 <vuk47o$3qkbb$1@dont-email.me> <vuk6b6$3l184$1@dont-email.me>
 <vuls34$1bf1j$4@dont-email.me> <vun87k$2m24h$2@dont-email.me>
 <vunb06$2fjjl$5@dont-email.me> <vuo57j$3h5l9$2@dont-email.me>
 <vuoath$3ljma$1@dont-email.me> <vuohgi$3td7u$1@dont-email.me>
 <vuonh6$2g74$2@dont-email.me> <vupeor$qf60$1@dont-email.me>
 <vupu0r$18vrc$1@dont-email.me> <vuqj5u$1rljg$1@dont-email.me>
 <vuql8e$1svmd$1@dont-email.me> <vur7vd$2dvvs$1@dont-email.me>
 <vur9t9$2gjif$1@dont-email.me> <vurasr$2hkih$1@dont-email.me>
 <vurbgd$2gjif$2@dont-email.me> <vurgt8$2n355$1@dont-email.me>
 <vuric8$2gjif$3@dont-email.me> <vutepm$gmbi$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 30 Apr 2025 23:55:56 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2600536"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vutepm$gmbi$4@dont-email.me>
Bytes: 4194
Lines: 76

On 4/30/25 11:15 AM, olcott wrote:
> On 4/29/2025 5:03 PM, Richard Heathfield wrote:
>> On 29/04/2025 22:38, olcott wrote:
>>
>> <snip>
>>
>>>
>>> int DD()
>>> {
>>>    int Halt_Status = HHH(DD);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return Halt_Status;
>>> }
>>>
>>> HHH is correct DD as non-halting BECAUSE THAT IS
>>> WHAT THE INPUT TO HHH(DD) SPECIFIES.
>>
>> You're going round the same loop again.
>>
>> Either your HHH() is a universal termination analyser or it isn't. 
> 
> The domain of HHH is DD.

Then in isn't a Halt Decider, a the domain for Halt Deciders is the 
description of any actual programs.

> 
>> If it isn't, it's irrelevant to the Halting Problem, 
> 
> It correctly refutes the conventional proof of the
> Halting Problem proofs. The "impossible" input specifies
> non-halting behavior and the contradictory part of DD
> is unreachable code.

No it doesn't, as it gives the wrong answer, and the code is REACHABLE, 
just not by HHH's psrtial emulation, which doesn't count.

Halt Decider, by their definition, are supposed to answer about the 
behavior of the program described to it when it is run.

DD when run Halts, because the HHH(DD) that it calls returns 0.

THus HHH(DD) returning 0 is an error.

Your attempts to lie with the strawman error of trying to redefine the 
already define requirements just shows you are just a stupid liar.

Your logic says a 1/2 mile trail that you get off after walking 50 feet 
can be corrected described as never ending, as you didn't reach it with 
your "correct hiking".

> 
> Have you ever done any actual programming?

It seems you haven't

> 
>> and we can ignore it. If it is, however, then we know that it doesn't 
>> work for all inputs, even if (as you claim) it works for one.
>>
>> <snip>
>>
>>> DD <is> the Halting Problem counter-example input to HHH.
>>>
>>>> for the same reason we can't devise a universally accurate 
>>>> termination analyser that executes the code to see what happens.
>>>>
>>>
>>> There is no evidence of that.
>>
>> Sure there is. Not just evidence, but an actual, rigorous, 
>> mathematical proof.
>>
> 
>