Re: Functions computed by Turing Machines MUST apply finite string transformations to inputs

On 5/1/2025 11:57 PM, olcott wrote:

On 5/1/2025 9:40 PM, dbush wrote:

On 5/1/2025 10:34 PM, olcott wrote:

On 5/1/2025 8:58 PM, André G. Isaak wrote:

On 2025-05-01 19:09, 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.

>
IOW something you've pulled out of your ass.
>

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.

>
We were discussing functions. Functions don't have inputs or outputs; they have domains and codomains. ALGORITHMS have inputs and outputs, and you keep conflating the two.
>

Specific finite string transformation rules are
applied to inputs to derive outputs.

>
Please point to a definition of 'function' which mentions "finite string transformation rules". This may be a useful way of viewing some (but certainly not all) algorithms, but it has nothing to do with functions. Functions are simply a mapping from one set (the domain) to another set (the codomain) such that every element of the domain maps to one and only one element of the codomain.
>

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).

>
This is another baseless assertion that you've simply pulled out of your ass. If you think otherwise, please provide a concrete example
>

DD correctly emulated by HHH maps to NON-HALTING BEHAVIOR.
It really does, all that you have to do is PAY ATTENTION.

>
Whether DD emulated by HH maps to halting or non-halting behaviour is entirely dependent on which function is being computed.
>
André
>

>
We are computing the halt function

>
i.e. this function:
>
>
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
>
(<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
>
>
Which has been proven to be uncomputable, as shown by Linz and as you have *explicitly* agreed is correct.
>

FOR THE INPUT NOT ANY DAMN THING ELSE
FOR THE INPUT NOT ANY DAMN THING ELSE
FOR THE INPUT NOT ANY DAMN THING ELSE
FOR THE INPUT NOT ANY DAMN THING ELSE
>
FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG
FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG
FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG
>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
Replacing the code of HHH with an unconditional simulator and subsequently running HHH(DD) specifies recursive
simulation such that DD cannot possibly reach its
"return instruction" (final halt state). Thus HHH
is correct to reject DD as non halting.

>
So you changed the input.  Changing the input is not allowed.
>

 I never changed the input.

Yes you did.  You hypothesize changing the code of HHH, and HHH is part of the input. So you changed the input.
Changing the input is not allowed.

 

>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then
>
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
>

>
And *yet again* you lie by implying that Sipser agrees with you when it's been proven *on multiple occasions* that he does not:
>

 Professor Sipser gave me permission to quote
those words above Ben verified that too.
 Assuming the those words are true I AM PROVED CORRECT.
Why would professor Sipser agree with words that are not true?

Because he didn't agree to what you think he did, as proven below by Ben's interaction.
Your posting of this dishonestly implies that he agreed with what *you* thought we did, and continuing to post after the below proof that he in fact did not shows that you are *intentionally* misrepresenting what he agreed to, further proving that there is no limit to what you'll lie about to avoid admitting you wasted the last 22 years by failing to understand proof by contradiction.
Also, as you yourself said:
On 4/3/2025 12:25 AM, olcott wrote:
 > Appeal to authority is an error.

 

On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
 > I exchanged emails with him about this. He does not agree with anything
 > substantive that PO has written. I won't quote him, as I don't have
 > permission, but he was, let's say... forthright, in his reply to me.
>
Your dishonesty knows no bounds.