> A function can be seen as a machine that takes in value and gives you back another value. It is what we use in maths to map numbers (input) to other numbers (output).
That's absolutely wrong (mathematically). A function is a relation between two sets, where one value from the first set is related to at most one value from the second set.
It's kind of weird to read discussions on how "functions in programming languages are weird because they're not functions in the mathematical sense", but then you see how for most people a function denotes a machine that performs work in time (all physical concepts), rather than the idealised mathematical definition. Doubly weird when the author is someone trying to explain calculus and has presumably sat through a lot of high-level mathematics classes.
Why is this "absolutely wrong"? This is a natural, useful and benign description of what a function is. It doesn't contradict the formal set-theoretic definition, which came long after mathematicians started talking about functions, and which isn't required at all to conceptually understand what a function is, just as nobody needs to know the Peano axioms to understand what the number 5 is.
I don't see any harm in saying that a function is like a machine.
Edit: And if really want to be pedantic, then we might as well say that a function is not a relation between sets, but just a relation (with the requirement that no element maps to two different elements), and therefore can be between proper classes as well (hence we have functors between categories). Also - there could exist other ways to axiomatize the notion of a function. They point is that the formal definition of a function is just a tool, not some metaphysical essence of what a function is.
Hi OP here. Thanks for stating that. You are absolutely right. It isn't a technically correct analogy. I apologize for that. When I was writing the article I didn't want to get into the details for the non-injective surjection that is not reversal and that a function is merely relation where we shouldn't introduce the element of "time" by thinking of it as a process. I intended to go through the function section as quick as possible (the same time in a way that readers can easily form a mental image of it), and get started on differentiation and integration, which are what they are on my page for.
Seconding this. I've had this discussion a number of times and even when people initially reject the "relation" definition, if you push them with the Socratic Method eventually they get to a point where they see it really is the only good way to define functions, regardless of how "laymen unfriendly" relations seem.
The 'machine' "definition" perpetuates as an idiom, with teachers who don't know any better teaching it so their students don't know any better, and it does great damage to math education.
What's wrong with thinking of such a relation as a "machine that takes in [a] value and gives you back another value"? This seems to me needless pedantry.
Nothing wrong per se - both definitions are right within their domains, i.e. programming¹ vs mathematics.
It's just that I keep hearing (usually from FP people) how procedural/oo/impure functional/what have you programming languages should stop calling their functions functions, because they're not functions in the mathematical sense and therefore confusing; but I have the gut feeling that the programming definition (machine with input and output - X comes in, Y comes out) is the actually more intuitive one, and here we see someone explaining mathematical functions using the programming definition. Ultimately, I suspect that for computable functions, there is no difference between the definitions.
So I found it interesting how here the "wrong/confusing" definition is used in place of the "correct" one.
¹ (edit) I mean programming as the engineering discipline of programming computing machines, not in the sense of discrete mathematics.
Although many reasonable choices are equivalent, you should also be more precise in what you mean by 'a machine'. If your machine is a regular expression matcher, for example, it cannot determine whether an arbitrary string contains matching parentheses pairs (http://en.m.wikipedia.org/wiki/Chomsky_hierarchy)
"Machine" is an abstract term, not limited to Turing machines. Somebody who is just learning about functions has no understanding of what "computable" means, nor why should something be "uncomputable" according to some specific definition of a machine. We can invent in our minds all kinds of machines that don't exist in the real world: Oracle machines have existed in recursion theory since the time of Turing.
If f is a function that tells us if a given Turing machine halts on a given input, there is nothing wrong about imagining this as a machine that receives a string and outputs a True/False answer. That no such machine can exist in the real world under some physical interpretation of the Church-Turing thesis is just a further observation - it has nothing to do with the correctness or usefulness of this formulation.
I think it is because we accidentally introduced the concept of time, which is a foreign concept to maths (but not to us), when talking about "machines" and the process of "taking [x] and giving you back [y]".
> A function can be seen as a machine that takes in value and gives you back another value. It is what we use in maths to map numbers (input) to other numbers (output).
That's absolutely wrong (mathematically). A function is a relation between two sets, where one value from the first set is related to at most one value from the second set.
It's kind of weird to read discussions on how "functions in programming languages are weird because they're not functions in the mathematical sense", but then you see how for most people a function denotes a machine that performs work in time (all physical concepts), rather than the idealised mathematical definition. Doubly weird when the author is someone trying to explain calculus and has presumably sat through a lot of high-level mathematics classes.