Functions as machines and relationships

In brief

Press a labeled button on a vending machine and, assuming the machine works and is stocked, the same specific item comes out every single time you press that button. Press a different button and a different item may come out, or possibly the same item made available under two labels; what never happens, in a working machine, is one button sometimes yielding one item and other times yielding a different one. That reliable, one output per input behavior is the entire content of what a function is in mathematics. It has nothing to do with whether a tidy formula describes it, and everything to do with dependable correspondence between an input and exactly one output. Most people meet functions first as formulas to graph and only later, if ever, see that the formula is a convenience, not the definition.

The full treatment

First look: the vending machine

Suppose a machine has buttons labeled A1 through F6, each dispensing a snack. Button B4 dispenses the same bag of pretzels every time it is pressed, assuming the machine has not been restocked with something else in that slot. That is the essential guarantee: one input, exactly one output, every time. Notice something else the machine allows without breaking this guarantee: button C4 might dispense the identical bag of pretzels that B4 dispenses. Two different inputs sharing one output does not violate the rule at all; the rule only forbids one input producing two different outputs on different occasions. A function, in other words, does not require that every output be reached by only one input; it requires that every input be tied to only one output.

Building the idea: what makes something a function

Compare two candidate relationships to sharpen the boundary. "The age of a given person, this year" is a function of the person, because each person has exactly one age at a given time, no matter how many other people share that same age. "A movie this person would recommend" is generally not a function of the person alone, because a single person can have several movies they would genuinely recommend, with no single correct output the relationship is obligated to return. The distinguishing test is not whether the relationship feels dependable in everyday language; it is whether, for every allowed input, there exists exactly one designated output, no more and no fewer.

The formal model: domain, codomain, and the input output rule

State this precisely. A function f assigns to every element x of a set called the domain exactly one element, written f of x, of a set called the codomain, and this is written f colon domain arrow codomain. The domain specifies every valid input. The codomain specifies the set the outputs are drawn from, though not every element of the codomain need actually be produced; the elements that are actually produced form a subset of the codomain called the range or image. The notation f of x denotes one single, specific value for each x in the domain, fixed by whatever rule defines f, with no ambiguity and no exception permitted anywhere in the domain.

Derivation: three representations of the same function, and why a formula is not the definition

Take the rule f of x equals two x plus one, defined for the whole numbers one through five. This can be represented as a formula, as just written. It can equally be represented as a table of pairs: one paired with three, two paired with five, three paired with seven, four paired with nine, five paired with eleven. It can equally be represented, most fundamentally, as a set of ordered pairs, which is in fact the formal, set theoretic definition of a function: a set of ordered pairs such that no two pairs share the same first element while disagreeing on the second. A graph is simply the picture of that same set of ordered pairs, plotted as points in a plane, a representation covered in its own right once coordinates are introduced. The formula is only one convenient way of stating the rule that generates this set of pairs; plenty of legitimate functions have no simple formula at all, such as a lookup table built from measured data, a rule defined by cases, or a rule such as "the nth digit of pi," each of which assigns exactly one output to every input while resisting a single tidy algebraic expression.

Testing whether a relationship is a function

A relationship fails to be a function the moment some single input is tied to two conflicting outputs. Consider the relationship between x and y given by y squared equals x. At x equals four, both y equals two and y equals negative two satisfy the relationship, since both square to four; one input, x equals four, is tied to two different candidate outputs, so this relationship is not a function of x. Compare this with y equals the square root of x, understood by convention as selecting only the nonnegative root: at x equals four, this rule designates exactly one output, two, discarding negative two by an explicit choice built into the definition of the square root symbol. The two relationships describe the same underlying equation, but only the second, with its extra convention resolving the ambiguity, qualifies as a function.

Lineage

Gottfried Wilhelm Leibniz coined the term function in the late seventeenth century, using it for a quantity associated with points on a curve, such as a slope or a length. Leonhard Euler, in the eighteenth century, extended the term to cover any expression built algebraically from a variable and constants, a notion still tied closely to formulas. The modern, formula free definition, a rule pairing each element of one set with exactly one element of another, took shape through the nineteenth century, notably in the work of Peter Lejeune Dirichlet, who studied functions defined arbitrarily, case by case, without any algebraic expression at all, precisely to handle correspondences that no formula could capture. The full set theoretic formulation of a function as a set of ordered pairs became standard mathematical practice in the twentieth century, once set theory itself had been established as a common foundation.

The strongest case for it

The domain, codomain, and one output per input definition covers every case mathematics needs to handle: formulas, tables, graphs, algorithms, and physical laws that relate one measured quantity to another all fit inside this single concept, letting the same tools, composing two functions, inverting a function, checking whether a function is one to one, apply uniformly regardless of how the rule happens to be stated. It is the concept underlying the rate at which a function changes, underlying a well behaved computer procedure that must return a definite result for every valid input, and underlying physical laws such as position depending on time. Its reach across such different settings comes precisely from refusing to tie the definition to any particular representation.

The strongest case against it

Not every relationship that feels dependable survives scrutiny as a genuine function once the domain is examined closely. The rule f of x equals one divided by x is not a function on the whole set of real numbers, since division by zero is undefined; it is a function only once the domain is explicitly restricted to exclude zero, and this restriction, easy to omit, is where a great deal of real error originates. A first common misconception is believing a function must be expressible as a single tidy formula, which the lookup table and case defined examples above already contradict. A second common misconception is confusing the property that every output is used by only one input, called being one to one, with the defining property of a function itself, that every input has only one output; these are two separate conditions, and a function can satisfy the second without satisfying the first, as the button B4 and C4 example showed.

Where it stands now

The domain, codomain, one output per input definition of a function is fully settled and universally adopted across mathematics and every field that applies it; there is no live dispute about what a function is. What remains genuinely open in any particular case is a modeling question distinct from this settled definition: which specific function best describes an observed real world dependency, a question answered by evidence and fit rather than by the definition of function itself.

Test yourself

A parking garage charges according to this rule: the first hour costs five units of currency, and every additional hour or part of an hour costs two more units. Construct this dependency as a function. State a domain you consider sensible, and justify explicitly whether you are treating the input as a continuous duration or as a count of hour blocks, since the two choices lead to different domains and different rules. Write the rule precisely enough that it produces exactly one price for any valid duration in your domain, with no duration left undefined. Finally, consider the reverse relationship, the duration corresponding to a given price, and determine whether that reverse relationship is itself a function of price, explaining clearly why or why not.