Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.swapon.de!news.in-chemnitz.de!3.eu.feeder.erje.net!feeder.erje.net!npeer.as286.net!npeer-ng0.as286.net!news.neodome.net!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Turing computable functions
Date: Tue, 25 Mar 2025 18:33:05 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <3c5ff26d0202f146c0580fff7b8bdfca15e4b23a@i2pn2.org>
References: <vruvsn$3tamc$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Mar 2025 00:32:28 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1762229"; 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: <vruvsn$3tamc$3@dont-email.me>

On 3/25/25 3:24 PM, olcott wrote:
> Cannot possibly derive any outputs not computed from
> their inputs.

Right, but the problem might require that.

> 
> A Turing machine halt decider cannot possibly report
> on the behavior of any directly executing process.
> No Turing machine can every do this. This has always
> been beyond what any Turing machine can ever do.

Sure it can for many inputs, because it can simulate some to completion 
and some to a repeat state, proving that they will not halt.

The problem is this doesn't

> 
> The best that any Turing machine halt decider can
> possibly do is determine the behavior that an input
> finite string specifies.

But that behavior is specified to be the behavior of the actual machine 
it represents, or equivalently, the behavior of the UTM that interprets it.

Remember, a UTM, by its definition, exactly reproduces *ALL* the 
behavior of the Turing Machine described by its input.

> 
> When we make these things 100% concrete in a language
> that has been fully operational for many years...
> 

Your problem is that those things HAVE been concrete for like 80 years, 
you just don;t

> int DD()
> {
>    int Halt_Status = HHH(DD);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }

Which is NOT a "Program" since it doesn't include the definitioin of HHH.

> 
> When an input finite string specifies a pathological
> relationship with its simulating halt decider the actual
> behavior that pathological relationship derives must
> be reported because THAT IS THE BEHAVIOR THAT IS SPECIFIED
> BY THIS INPUT FINITE STRING.
> 

But the program doesn't HAVE a "it's decider", only a decider that it 
was designed to cofound by being contrary, and does so by purely legal 
methods.

Note, the behavior of YOUR finite string is "Categpry Error" as it isn't 
a program.

Add the code for HHH to it, and its behavior is determied by UTM(DD) 
which will be halting if HHH(DD) returns 0 or just aborts its execution, 
and non-halting if HHH(DD) return 1 or loops forver.

THus, it is clear that there can be no correct answer from however you 
had defined HHH (which must have been defined BEFORE we could create the 
DD) but there *IS* a correct answer that other deciders could return, 
they just need to answer the opposite of HHH(DD).

Sorry, you are just proving you don't understand what you are talking about.