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

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

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.
 

Specify every single step of the mapping and you will
see that it has never been well defined. It has ONLY
ever been a leap to a conclusion.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer