Re: Turing Machine computable functions MUST apply finite string transformations to inputs

On 5/1/2025 9:26 PM, olcott wrote:

On 5/1/2025 8:14 PM, dbush wrote:

On 5/1/2025 9:09 PM, olcott wrote:

On 5/1/2025 7:32 PM, André G. Isaak wrote:

On 2025-05-01 14:15, olcott wrote:

On 5/1/2025 10:14 AM, André G. Isaak wrote:

On 2025-04-30 21:50, olcott wrote:

On 4/30/2025 7:17 PM, André G. Isaak wrote:

>

You are still hopelessly confused about your terminology.
>
Computable functions are a subset of mathematical functions, and mathematical functions are *not* the same thing as C functions. Functions do not apply "transformations". They are simply mappings, and a functions which maps every pair of natural numbers to 5 is a perfectly legitimate, albeit not very interesting, function.
>
What makes this function a *computable function* is that fact that it is possible to construct a C function (or a Turing Machine, or some other type of algorithm) such as int foo(int x, int y) {return 5;} which computes that particular function; but the C function and the computable function it computes are entirely separate entities.

>
computes the sum of two integers
by transforming the inputs into an output.
int sum(int x, int y) { return x + y; }
>
Computes no function because it ignores its inputs.
int sum(int x, int y) { return 5; }

>
All you're demonstrating here is that you have no clue what a function is, nor, apparently, do you have any desire to learn.
>
André
>

>
What I am explaining is that a halt decider
must compute the mapping FROM THE INPUTS ONLY
by applying a specific set of finite string
transformations to the inputs.

>
No. Halt deciders weren't even mentioned above. I was addressing your absurd claim that int foo(int x, int y) { return 5; } does not compute a function. This clearly indicates that you do not grasp the concept of "function".
>

>
This is a brand new elaboration of computer
science that I just came up with.
>
It is common knowledge THAT inputs must correspond
to OUTPUTS. What is totally unknown and brand new
created by me is HOW inputs are made to correspond
to OUTPUTS.
>
Specific finite string transformation rules are
applied to inputs to derive outputs.

>
In other words, you're simply looking at an algorithm to see what mapping it computes
>

>
What everyone else has been doing is simply GUESSING
that they correspond or relying on some authority
that say they must correspond. (Appeal to authority error).
>

>
False.  The halting problem proofs start with the assumption that the following requirements can be met and that HHH meets them:
>
>
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
>
A solution to the halting problem is an algorithm H that computes the following mapping:
>
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
>
>

 For all of these years no one ever noticed that
those requirements are incoherent

False.  The mapping exists and is well-defined, it's just that no algorithm can compute it, as Linz proved and you *explicitly* agreed.

because no one
actually took into account the exact details of
HOW inputs are mapped to OUTPUTS.
 

It doesn't matter how.  What matters is that no algorithm can compute the above well-defined mapping, as Linz proved and you *explicitly* agreed.

When you stupidly ask for an INCORRECT mapping

Category error.  Mappings just "are".  And this particular mapping is very useful, and an algorithm that would compute it would be even more useful.  But no algorithm can compute it, as Linz proved and you *explicitly* agreed.