Sujet : Re: Turing Machine computable functions apply finite string transformations to inputs
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theoryDate : 05. May 2025, 12:22:29
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <fa407a930a68fa6d034e6eba755bbdee761d5c27@i2pn2.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
User-Agent : Mozilla Thunderbird
On 5/4/25 10:49 PM, olcott wrote:
On 5/4/2025 7:21 PM, Richard Damon wrote:
On 5/4/25 6:15 PM, olcott wrote:
On 5/4/2025 2:21 PM, Richard Heathfield wrote:
On 04/05/2025 18:55, olcott wrote:
Changing my words then rebutting these changed
words is dishonest.
>
Functions computed by Turing Machines require INPUTS
and produce OUTPUTS DERIVED FROM THESE INPUTS.
>
Counter-example: a Turing Machine can calculate pi without any input whatsoever.
>
As Mikko rightly said: a Turing machine does not need to require an input.
>
>
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
IT IS NOT COMPUTING FUNCTION THEN
>
Right, not all Turing Machine compute Functions, they all do perform Computations.
>
Even those that know this pretend that they don't.
>
Computable functions are the basic objects of study in computability theory. Computable functions are the formalized analogue of the intuitive notion of algorithms, in the sense that a function is computable if there exists an algorithm that can do the job of the function, i.e. given an input of the function domain it can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
>
given an input of the function domain it can return the corresponding output.
>
Right, and the input to a Halt Decider is the representation of a Program,
Not exactly. It is a 100% specific precise sequence of encoded steps.
Not at all the same as a mere description.
Which means you don't understand what a representation means.
and the correct output is based on the behavior of that progrma when run.
>
It typically precisely coincides with the exact same
behavior as the direct execution.
It *MUST* coincide or it is just incorrrect.
My idea of a simulating termination analyzer
conclusively proves to all those with great
expertise in programming that this is not
always the case. You seem to lack sufficient
expertise in programming
No, your "idea" of "simulating termination analyzers" just proves that you don't understand the meaning of the words you are using,
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
DD correctly simulated by HHH cannot possibly
return anywhere. Most every expert C programmer
knows this.
But your HHH that you have defined doesn't do the correct simulation, and thus your statement is incorrect.
And when you remove the stipulation that the Halt7.c be included in the definition, then DD fails to be a program, as HHH isn't defined.
If you then fix that be saying HHH *IS* a correct simulator, then that HHH just fails to be a decider, as you say, it will never reach the final state for this diffferent input built on this different program (intentionally deceptively) called HHH, and thus not answer.
You are just proven to be a blantant ignorant pathological lying idiot.