On 30/04/2025 18:32, olcott wrote:

On 4/30/2025 11:11 AM, Richard Heathfield wrote:

On 30/04/2025 16:44, joes wrote:

Am Wed, 30 Apr 2025 10:09:45 -0500 schrieb olcott:

On 4/29/2025 5:01 AM, Mikko wrote:

Irrelevant. There is sufficient agreement what Turing
machines are.

Turing machine computable functions must apply finite string
transformation rues to inputs to derive outputs.

This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }

Yes it is, for all inputs.

Not much of a computation, though, is it?

It IS NOT a Turing Computable function

Are you saying that 5 can't be computed? You're braver than I
thought.

because it does not ever apply any finite
string transformation  rules to its inputs.

If you'd bothered to read the article, you'd have seen that I
addressed that point.

THE OUTPUTS MUST CORRESPOND TO THE INPUTS.
sum(4,3) returns 5 proving that sum is
not a Turing Computable function.

Not so. It just shows that sum() ignores its input and returns a
constant. That's a perfectly computable function.


--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

On 4/30/2025 11:11 AM, Richard Heathfield wrote:

On 30/04/2025 16:44, joes wrote:

Am Wed, 30 Apr 2025 10:09:45 -0500 schrieb olcott:

On 4/29/2025 5:01 AM, Mikko wrote:

Irrelevant. There is sufficient agreement what Turing machines are.

Turing machine computable functions must apply finite string
transformation rues to inputs to derive outputs.

This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }

Yes it is, for all inputs.

Not much of a computation, though, is it?

It IS NOT a Turing Computable function
because it does not ever apply any finite
string transformation  rules to its inputs.

THE OUTPUTS MUST CORRESPOND TO THE INPUTS.
sum(4,3) returns 5 proving that sum is
not a Turing Computable function.

Sure it is. You just don't know that that mean.

THe function given computes the Computable Function defined by the
mapping of all pair (x, y) -> the value 5.

That is a perfectly fine Function, and easily proved to be computable.

It isn't a correct function for computing the addition function that
maps the pair (x, y) -> x+y, but that wasn't what you said, because you
don't know what you are talking about.

You don't seem to understand that "Functions" are defined just by the
input -> output mapping that they specify.

They are Computable if some Turing Machine exists that can create that
whole mapping (via some representation method for the inputs/outputs)

But the "Computable Function" still isn't defined by the code fo that
Turing Machine, but by the mapping.

NO "Turing Machine" is a "Turing Computable Function" as they are
different categories of things.

Turing Machine as strictly defined by the rules that they are built on
that create the mappings they compute.

Functions (Computable or Not) are defined by the Mapping of Input to
Output that they are.


Turing Machine COMPUTE some Computable Function, they are not the
Function itself.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/30/25 6:09 PM, olcott wrote:

On 4/30/2025 2:55 PM, dbush wrote:

On 4/30/2025 1:32 PM, olcott wrote:

On 4/30/2025 11:11 AM, Richard Heathfield wrote:

On 30/04/2025 16:44, joes wrote:

Am Wed, 30 Apr 2025 10:09:45 -0500 schrieb olcott:

On 4/29/2025 5:01 AM, Mikko wrote:

Irrelevant. There is sufficient agreement what Turing machines are. >>>>>>

Turing machine computable functions must apply finite string
transformation rues to inputs to derive outputs.

This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }

Yes it is, for all inputs.

Not much of a computation, though, is it?

It IS NOT a Turing Computable function

Lying by misuse of terms.

A turing computable function is a mapping for which an algorithm
exists to compute it, not the algorithm itself.

Further use of "turing computable function" when what is meant is
"algorithm" will result in the former being replaced with the later in
future responses to your posts to make it clear what you are actually
talking about.

because it does not ever apply any finite
string transformation  rules to its inputs.

Sure it does.  It computes the mapping of all pairs of integers to the
number 5.

int sum(int x, int y) { return 5; }
Does not apply transformations to its inputs
to derive its outputs thus is no kind of computable
function not even for sum(2,3).

And there is no requirement that a Turing Machine, or a Function,
actually use its input.

Note sum(2,3) isn't a Function, it is an invocation of a Function.

You seem to have a lot of misunderstanding about the meaning of the
words you use.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-30 16:09, olcott wrote:

On 4/30/2025 2:55 PM, dbush wrote:

On 4/30/2025 1:32 PM, olcott wrote:

On 4/30/2025 11:11 AM, Richard Heathfield wrote:

On 30/04/2025 16:44, joes wrote:

Am Wed, 30 Apr 2025 10:09:45 -0500 schrieb olcott:

On 4/29/2025 5:01 AM, Mikko wrote:

Irrelevant. There is sufficient agreement what Turing machines are. >>>>>>

Turing machine computable functions must apply finite string
transformation rues to inputs to derive outputs.

This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }

Yes it is, for all inputs.

Not much of a computation, though, is it?

It IS NOT a Turing Computable function

Lying by misuse of terms.

A turing computable function is a mapping for which an algorithm
exists to compute it, not the algorithm itself.

Further use of "turing computable function" when what is meant is
"algorithm" will result in the former being replaced with the later in
future responses to your posts to make it clear what you are actually
talking about.

because it does not ever apply any finite
string transformation  rules to its inputs.

Sure it does.  It computes the mapping of all pairs of integers to the
number 5.

int sum(int x, int y) { return 5; }
Does not apply transformations to its inputs
to derive its outputs thus is no kind of computable
function not even for sum(2,3).

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. [I won't call that function 'sum()' because that would be misleading, but the the *name*
assigned to a C function has no necessary relation to the function it
computes. It's good programming practice to give functions descriptive
names but nothing in the C standard requires it).

You keep conflating C functions/Turing Machines with computable
functions and as a result come across as completely ignorant about the
topic you purport to be discussing. No C function or Turing Machine is a computable function. They are ways of expressing algorithms.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/30/25 11:50 PM, olcott wrote:

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

On 2025-04-30 16:09, olcott wrote:

On 4/30/2025 2:55 PM, dbush wrote:

On 4/30/2025 1:32 PM, olcott wrote:

On 4/30/2025 11:11 AM, Richard Heathfield wrote:

On 30/04/2025 16:44, joes wrote:

Am Wed, 30 Apr 2025 10:09:45 -0500 schrieb olcott:

On 4/29/2025 5:01 AM, Mikko wrote:

Irrelevant. There is sufficient agreement what Turing machines >>>>>>>>> are.

Turing machine computable functions must apply finite string
transformation rues to inputs to derive outputs.

This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }

Yes it is, for all inputs.

Not much of a computation, though, is it?

It IS NOT a Turing Computable function

Lying by misuse of terms.

A turing computable function is a mapping for which an algorithm
exists to compute it, not the algorithm itself.

Further use of "turing computable function" when what is meant is
"algorithm" will result in the former being replaced with the later
in future responses to your posts to make it clear what you are
actually talking about.

because it does not ever apply any finite
string transformation  rules to its inputs.

Sure it does.  It computes the mapping of all pairs of integers to
the number 5.

int sum(int x, int y) { return 5; }
Does not apply transformations to its inputs
to derive its outputs thus is no kind of computable
function not even for sum(2,3).

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; }

No, that *IS* a Function that is computed, it perhaps would be better
names "five".

Functions do not need to use their inputs.

Do you have a source that says they do? or is this just one of your
normal brain farts.

[I won't call that function 'sum()' because that would be misleading,
but the the *name* assigned to a C function has no necessary relation
to the function it computes. It's good programming practice to give
functions descriptive names but nothing in the C standard requires it).

You keep conflating C functions/Turing Machines with computable
functions and as a result come across as completely ignorant about the
topic you purport to be discussing. No C function or Turing Machine is
a computable function. They are ways of expressing algorithms.

André

The complete ignorance is to expect HHH(DD)
to report on DD(DD). That is just not the way
that reality works.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/1/25 12:30 AM, olcott wrote:

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

On 4/30/25 6:09 PM, olcott wrote:

On 4/30/2025 2:55 PM, dbush wrote:

On 4/30/2025 1:32 PM, olcott wrote:

On 4/30/2025 11:11 AM, Richard Heathfield wrote:

On 30/04/2025 16:44, joes wrote:

Am Wed, 30 Apr 2025 10:09:45 -0500 schrieb olcott:

On 4/29/2025 5:01 AM, Mikko wrote:

Irrelevant. There is sufficient agreement what Turing machines >>>>>>>>> are.

Turing machine computable functions must apply finite string
transformation rues to inputs to derive outputs.

This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }

Yes it is, for all inputs.

Not much of a computation, though, is it?

It IS NOT a Turing Computable function

Lying by misuse of terms.

A turing computable function is a mapping for which an algorithm
exists to compute it, not the algorithm itself.

Further use of "turing computable function" when what is meant is
"algorithm" will result in the former being replaced with the later
in future responses to your posts to make it clear what you are
actually talking about.

because it does not ever apply any finite
string transformation  rules to its inputs.

Sure it does.  It computes the mapping of all pairs of integers to
the number 5.

int sum(int x, int y) { return 5; }
Does not apply transformations to its inputs
to derive its outputs thus is no kind of computable
function not even for sum(2,3).

And there is no requirement that a Turing Machine, or a Function,
actually use its input.

Computable functions are the basic objects of study in
computability theory. Computable functions are the
formalized analogue of the intuitive notion of algorithms,
in the sense that a function is computable if there exists
an algorithm that can do the job of the function, i.e.
*given an input of the function domain it can return the*
*corresponding output*
https://en.wikipedia.org/wiki/Computable_function

Right, and the study is whether or not given Functions are in fact
Computable.

Note, the above definition of a Computable Function makes it clear that
not all functions are Computable, as they are only computable if such an algorithm can be found.

Then the relation between the input and the output
is violated.

Which relation?

The above definitions talks about the domain of the Function itself,
which is the specified mapping of input to output, with no requirement
on how that mapping was specifed.

And then there is the mapping generated by the algorithm, which only
makes the Function computable if its output matches the above mapping
for all input.

Only the latter is restricted by the finite string manipulation ability
of the alogrithm. There is nothing wrong by that definition for a
Function to be specified based on something else.

The Function only becomes Computable, if we can find an algorithm that implements it.

The key fact you seem to have missed is that when a Function is
specified, it isn't necessarily Computable. This is illustrated by the
Halting Funtion, which maps program/input pairs to Halting or
Not-Halting based on their behavior when run.

These can be given to Turing Machines via the ability to represent all
programs as finite strings, and we can try to see if the TM can figure
out, in finite time, that behavior specified by that input, which *IS*
what that program does when it is run,

A simple fact that seems to be above your ability to understand.

Note sum(2,3) isn't a Function, it is an invocation of a Function.

You seem to have a lot of misunderstanding about the meaning of the
words you use.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/1/25 12:26 AM, olcott wrote:

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

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

On 4/30/2025 11:11 AM, Richard Heathfield wrote:

On 30/04/2025 16:44, joes wrote:

Am Wed, 30 Apr 2025 10:09:45 -0500 schrieb olcott:

On 4/29/2025 5:01 AM, Mikko wrote:

Irrelevant. There is sufficient agreement what Turing machines are. >>>>>>

Turing machine computable functions must apply finite string
transformation rues to inputs to derive outputs.

This is not a function that computes the sum(3,2):
int sum(int x, int y) { return 5; }

Yes it is, for all inputs.

Not much of a computation, though, is it?

It IS NOT a Turing Computable function
because it does not ever apply any finite
string transformation  rules to its inputs.

THE OUTPUTS MUST CORRESPOND TO THE INPUTS.
sum(4,3) returns 5 proving that sum is
not a Turing Computable function.

Sure it is. You just don't know that that mean.

Computable functions must apply finite string
transformations to inputs. sum does not do that.

Sure it does. It applies the erase transform to ignore them.

You just don't understand what finite string transformations means.

And you claim to base your logic on the meaning of the words, when you
don't in fact know the meaning of the words.

THe function given computes the Computable Function defined by the
mapping of all pair (x, y) -> the value 5.

That is a perfectly fine Function, and easily proved to be computable.

It isn't a correct function for computing the addition function that
maps the pair (x, y) -> x+y, but that wasn't what you said, because
you don't know what you are talking about.

You don't seem to understand that "Functions" are defined just by the
input -> output mapping that they specify.

They are Computable if some Turing Machine exists that can create that
whole mapping (via some representation method for the inputs/outputs)

But the "Computable Function" still isn't defined by the code fo that
Turing Machine, but by the mapping.

NO "Turing Machine" is a "Turing Computable Function" as they are
different categories of things.

Turing Machine as strictly defined by the rules that they are built on
that create the mappings they compute.

Functions (Computable or Not) are defined by the Mapping of Input to
Output that they are.


Turing Machine COMPUTE some Computable Function, they are not the
Function itself.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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é

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/05/2025 21:41, dbush wrote:

<snip>

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

And it is proven that halt deciders don't exist

To be more precise, it is proven that /universal/ halt deciders
don't exist. There is nothing stopping us writing a halt decider
that works correctly for /some/ inputs.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/05/2025 21:15, olcott wrote:

<snip>

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.

I don't think that's in dispute. Were a successful universal halt
decider to be possible (which of course it isn't), it would have
no information available to it except what's on the tapes, which
consist of finite strings of symbols, and it must use such
information as it has in order to correctly report on the nature
of the input program. Yes, it's a mapping. Which transformations
are to be applied will undoubtedly depend heavily on the input
program's internal structure, but transformations there must be,
even if they're as simple as turning "return 0" into "it halts".

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

Everyone assumes that it is correct to ignore
the required finite string transformations
that mandate DD correctly emulated by HHH
cannot possibly reach its own final halt state
no matter what of an infinite set of HHH's does.

Word salads do not a proof overturn.

HHH can't emulate DD correctly because it can only ever get as
far as the first line of the emulation before it recurses. It
never reaches the if() because the runaway recursion will crash
the program before it gets that far.

Since HHH fails to report its result, it is not a working
halt-decider.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/1/25 4:15 PM, 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.

Right, it only gets to USE the input. The input does FULLY SPECIFY the algorithm of the program described by it, and thus all the information
that defines what the direct execution

The limitation of what the decider can do has no bearing on the ability
to ask the queastion. Since the question of the behavior is fully
defined, and all the information to feed that definition is present, it
is a fair question.

The fact that the decider just can't get the answer, and we can do this
for ANY possible decider, the mapping is just shown to be uncomputable.

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

Everyone assumes that it is correct to ignore
the required finite string transformations
that mandate DD correctly emulated by HHH
cannot possibly reach its own final halt state
no matter what of an infinite set of HHH's does.

And you just shows that you are a pathological liar, since it has been
shown that HHH doesn't do the correct emuation that you claim.

This just shows that you concept of logic includes the right to lie
about what you are doing, and thus your logic is just worthless.

Sorry, but that *IS* what you are showing, that you have no concept of
what Truth or Logic actually is.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

To understand what a halt decider does you need to first understand what
the halting function is. And to understand that, you must first
understand what a function is. You clearly do not.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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é

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/1/25 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.

You mean you are admitting that you didn't understand that this
relationships HAS been precisely definied?

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

That is what an algorithm can do. It isn't how a Function works.

Something you have demonstrated you failure to understand.

Perhaps the problem is that "Functions" in Computation Theory are sort
of abstract stating results without needing to specify hwo they are
gotten. We can specify how, but it is not limited by the rules of
algorithms, since not all Functions are computable.

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

No, people have been looking at the DEFINITIONS. Something you don't
seem to understand.

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

But since HHH doesn't correctly emulate DD, you are just showing that
you "logic" is based on lying about false premises.

Sorry, this seems to be your novel concept, that we can just make up
what we want and lie about things.

To understand what a halt decider does you need to first understand
what the halting function is. And to understand that, you must first
understand what a function is. You clearly do not.

André

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/1/25 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 because no one
actually took into account the exact details of
HOW inputs are mapped to OUTPUTS.

No, YOU are incoherent as you don't understand the nature of what you
are talking about.

When you stupidly ask for an INCORRECT mapping
that does not entail any actual limit to computation.

No, you don't know the definiton of a correct mapping, because you chose
to make yourself ignorant and thus stupid about the field.

*DD correctly emulated by HHH DOES NOT HALT*
*DD correctly emulated by HHH DOES NOT HALT*
*DD correctly emulated by HHH DOES NOT HALT*

Your specified HHH doesn't correctly emulate DD, so you are shown to
just be a pathetic pathological liar who is totally ignorant of what he
is talking about.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-01 19:55, olcott wrote:

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.

Mappings don't HAVE steps. Again, you are confusing functions with
algorithms.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 01.mei.2025 om 22:15 schreef olcott:

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.

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

A correct decider would use finite string transformations and conclude
that the input describes a halting program. This is possible, because
the direct execution and world-class simulators perform those
transformations correctly. A program that is not able to do the correct
finite string transformation is just an erroneous program, even if it
does not crash by violations of the x86 code.
The input to HHH describes a halting program, but HHH has a bug so that
it does not complete the finite string transformations, but it aborts
them prematurely.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 02.mei.2025 om 03:26 schreef olcott:

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 because no one
actually took into account the exact details of
HOW inputs are mapped to OUTPUTS.

When you stupidly ask for an INCORRECT mapping
that does not entail any actual limit to computation.

*DD correctly emulated by HHH DOES NOT HALT*
*DD correctly emulated by HHH DOES NOT HALT*
*DD correctly emulated by HHH DOES NOT HALT*

Only because HHH does not allow it to halt. It prematurely aborts before
the simulation of DD can halt. That has nothing to do with the behaviour specified in the input to HHH. A bug in HHH makes it impossible for HHH
to analyse the Halt7.c code, included in DD, so that it misses the
behaviour of a conditional halt specified in the input.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 02.mei.2025 om 03:55 schreef olcott:

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.

There is only one step in the mapping.
You are confusing the mapping with the computation.
The mapping of a halting program to 1 and of a non-halting program to 0
is only one step.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 02.mei.2025 om 04:25 schreef olcott:

On 5/1/2025 9:10 PM, André G. Isaak wrote:

On 2025-05-01 19:55, olcott wrote:

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.

Mappings don't HAVE steps. Again, you are confusing functions with
algorithms.

André

In other words people just guess that a mapping exists or not?
THE MAPPING FROM INPUTS TO OUTPUTS IS BY FINITE STRING TRANSFORMATIONS.

No, that is how a mapping is computed. The mapping itself is defined in
other ways.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/1/25 10:25 PM, olcott wrote:

On 5/1/2025 9:10 PM, André G. Isaak wrote:

On 2025-05-01 19:55, olcott wrote:

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.

Mappings don't HAVE steps. Again, you are confusing functions with
algorithms.

André

In other words people just guess that a mapping exists or not?
THE MAPPING FROM INPUTS TO OUTPUTS IS BY FINITE STRING TRANSFORMATIONS.

No, the computation is by a finite algorithm of finite string operations.

The mapping is a mapping from one object to another.

We CAN define a transformation (it isn't based on a finite algorithm)
that says map string x to the halting status of the direct execution of
the program that x represents.

That *IS* a transformation of finite strings. It is just not a
transformation based on a finite algorithm.

The mapping to compute the sum function is from integers
transformed by the steps of arithmetic to an integer OUTPUT.

So, that particular mapping can be defined in terms of operations

int sum(int x, int y) { return 5; }
The above mapping IS NOT for the sum function.

An no one said it was.

They said that it was a computation that computed a function that
correctly answered the question of sum(3, 2) which is 5.

You are just showing your lack of reading comprehension.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/1/25 9:55 PM, olcott wrote:

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.

The mapping is infinite in size, so can't be fully written out.

Mappings don't HAVE "Steps", so you are showing your stupidity.

Now, if you claim that the results of running a program and seeing what
it does have never been defined, then I guess you need to return all the
pay you got for claiming to write programs that said they acheived
specified requirements.

Now, in the field of Olcott Programming, where programs don't need to
contain all their code, maybe the claim is true, but that isn't what
people talk about when they talk about programs, and it your own invention.

All you are doing is proving your utter ignorance of what you talk about.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)