Re: Turing computable function for sum of two integers

On 4/30/2025 8:24 PM, olcott wrote:

On 4/30/2025 6:55 PM, Richard Damon wrote:

On 4/30/25 1:36 PM, olcott wrote:

On 4/29/2025 4:50 AM, Mikko wrote:

On 2025-04-28 19:55:35 +0000, olcott said:
>

On 4/28/2025 11:01 AM, dbush wrote:

On 4/28/2025 11:52 AM, olcott wrote:

On 4/28/2025 4:01 AM, Mikko wrote:

On 2025-04-16 17:36:31 +0000, olcott said:
>

On 4/16/2025 7:29 AM, Richard Heathfield wrote:

On 16/04/2025 12:40, olcott wrote:

sum(3,2) IS NOT THE SAME AS sum(5,2).
IT IS EITHER STUPID OR DISHONEST FOR YOU TO TRY TO
GET AWAY FOR CLAIMING THIS USING THE STRAW DECEPTION
INTENTIONALLY INCORRECT PARAPHRASE OF MY WORDS.

>
Whether sum(3,2) is or is not the same as sum(5,2) is not the question. The question is whether a universal termination analyser can be constructed, and the answer is that it can't.
>
This has been rigorously proved. If you want to overturn the proof you've got your work cut out to persuade anyone to listen, not least because anyone who tries to enter into a dialogue with you is met with contempt and scorn.
>
The proof stands.
>

>
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
>
Not freaking allowed to look at any damn thing
else besides the freaking input. Must compute whatever
mapping ACTUALLY EXISTS FROM THIS INPUT.

>
A halt decider is is not allowed to compute "whatever" mapping. It is
required to compute one specific mapping: to "no" if the computation
described by the input can be continesd forever without halting, to
"no" otherwise.
>

>
It must do this by applying the finite string transformation
rules specified by the x86 language to the input to HHH(DD).
>
This DOES NOT DERIVE THE BEHAVIOR OF THE DIRECTLY EXECUTED DD.
It DOES DERIVE DD EMULATED BY HHH AND ALSO DERIVES THE RECURSIVE
EMULATION OF HHH EMULATING ITSELF EMULATING DD.
>

>
>
In other words, no H exists that satisfies the following requirements,

>
BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.

>
You have not proven that the requirements are wrong in any sense.
>

>
int sum(int x, int y) { return 5; }
Is NOT a Turing Computable function for the sum of two integers.

>
But it *
>

>
int sum(int x, int y) { x + y; }
Is a Turing Computable function for the sum of two integers.
>

>
No, it is an algorithm in the C language to compute the Computable Function for addition.
>
No algorithm/program is a "Function" in the computation theory sense of the word, that is just a category error.
>
algorithms/programs COMPUTE Functions, which are just the complete mapping of inputs to outputs that the Function Defines.
>

 YES that means that HHH(DD) is not allowed to report
on the direct execution of DD(DD) because the input
to HHH(DD) maps to something else.

Which is another way of saying that HHH doesn't meet the requirements to be a solution to the halting problem:
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

 When one maps an input to an output one must apply
very specific finite string transformation rules.
One cannot simply guess what one wants to end up
with and simply assume that this mapping is correct.
 

If the mapping an algorithm computes doesn't match the desired mapping, then the algorithm isn't correct for the desired mapping.

*Replacing the code of HHH with an unconditional simulator and subsequently running HHH(DD) DOES NOT HALT*

Obviously, but that clearly changes the input.
Changing the input is not allowed.

 

Being Computable just means that an algorithm/program exists that computes it.
>
Perhaps you need to go back to Freshman Programming to learn the meanings of the words you are misusing.

 No level of computer science education ever gets
around to specifying the details of how the mapping
from inputs to outputs must occur.
 I came up with this on my own. Turing Machine algorithms
that compute functions must apply finite string transformations
to inputs to derive outputs.
 

And no algorithm can compute this mapping, as Linz proved and you *explictly* agreed is correct:
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

That means that replacing the code of HHH with an unconditional simulator and subsequently running HHH(DD) DOES NOT HALT!
 

Obviously, but that clearly changes the input.
Changing the input is not allowed.