Sujet : Re: How computable functions actually work. (was Flibble)
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theoryDate : 23. Apr 2025, 23:34:00
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <c92fc7ff6e960dfcc382f2ad579c4ff1c5f4a7a9@i2pn2.org>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
On 4/23/25 12:27 PM, olcott wrote:
On 4/23/2025 6:15 AM, Richard Damon wrote:
On 4/23/25 12:14 AM, olcott wrote:
On 4/22/2025 9:33 PM, Richard Damon wrote:
On 4/22/25 6:19 PM, olcott wrote:
>
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
>
Yes, so the results can only BE what is computable, but as pointed out, the correct answer need not be.
>
>
That would seem to indicate an error in the original
problem specification.
>
No, just in your understanding of it.
>
>
Whatever can be derived by applying finite string
transformation to input finite strings <is> computable.
>
No, and the problem is you don't actually understand the meaning of the words you are using.
>
The point it that your phrase "Computations are finite string transformations" is not a definition, but just a description.
int sum(int x, int y) { return x + y; }
It does conclusively prove that HHH is not allowed
to report on the behavior of the direct execution
of DD for the same reason that sum(3,2) cannot report
on the sum of 4 + 3.
How?
That is the DEFINITION of the answer to the input requested.
Your HHH is loke:
int sum(int x, int y) { return x*y; }
Since it doesn't return about the halting behavor of its input.
Also, you ignore part of the input, thinking that DDD calls an HHH that doesn't abort, when the HHH that it calls does abort
Thus, all you are doing is proving that you are just a stupid liar that doesn't know what he is talking about.
The finite string transformations to the machine code
of DD according the definition of the x86 language
ALREADY SPECIFIES BEHAVIOR THE IS NOT THE BEHAVIOR
OF THE DIRECTLY EXECUTED DD.
But it *IS* the behavior of the directly executed DD, at least when you complete it to make it a progeram by including the code for the actual HHH tha it calls.
Your DD that excludes the code for HHH as not part of the input just doens't have behavior and is a category error.
Note, NOTHING in the definition of the X86 language says that a call to a function at the address of HHH means to emulate the code at the address given as a parameter.
Sorry, you are just showing your stupid ignorance of what you are talking about.
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
The call to HHH(DD) from DD simulated by HHH doesn't return only do to the failure of HHH to correctly emulate its input.
You can't blame DD on that failure of HHH.
All you are doing is proving your stupid ignorance of what you are talking about.