“What is f(3)?” is the first question to ask about a function. The evaluate_fn exercises in the functions exercises start there. The arithmetic is not the point. The framing is. A function is not a formula to plug into; it is a mapping from inputs to outputs. Once you see it that way, evaluation becomes the basic operation behind the whole idea.
A function is a mapping, not a formula
Ronald Kneusel’s Math for Programming draws the distinction clearly. A function “in the typical algebra sense” is an expression like ; the more useful view is “closer to its role in a programming language: a process that maps inputs to outputs.” The formal definition states the mapping directly:
A function (or mapping), f, between two sets, S (the domain) and T (the image, codomain, or range), written as f : S → T, is a set of pairs, (s, t), s ∈ S, t ∈ T, such that every element of S pairs with one, and only one, element of T.
“One, and only one” gives you two requirements. Every input needs an output, so the function is defined on its whole domain. Each input also has exactly one output; a function cannot return two different answers for the same input. Programming enforces the second requirement: a function call returns one value, deterministically. That determinism lets you reason about a function instead of merely running it.
In code, the domain is the set of valid inputs, the codomain is the set of possible outputs, and the function is the rule pairing them. f : int → int in math is (x: number) => number in TypeScript. Same idea. The compiler gets its own spelling.
Evaluation is finding the output for one input
Evaluation means applying the mapping to one input: given , find the paired with it. For , the mapping says “double the input, add one.” So is . That is the entire operation. The rest is substitution, which the substitution article covers: replace with the value everywhere in the body, then simplify.
The two slip points from substitution appear here too. Carry the sign on a negative input: at is , not . A leading minus binds to the product, not to one factor: at is . The evaluate exercises put their traps in exactly these spots.
The genuinely new idea is the “one and only one” reading. When you see and are asked for , the question is “which single output does the mapping assign to 2?” The answer is 6, not “well, it could be several things.” A function assigns exactly one output to each input. Evaluation reads that assignment.
It is a function call
The code spelling is the arrow function:
const f = x => 2 * x + 1;
f(3); // 7
The parameter is the input, the body is the rule, and the call is the evaluation. Elixir makes the same move with a different equality sign - f = fn x -> 2 * x + 1 end then f.(3) - and both feel like algebra for the same reason: they are algebra. A function definition is a template, a call is a substitution, and evaluation is the result.
Why this matters here
The evaluate_fn skill comes first in the functions exercises because every other function skill uses the mapping frame. Composition asks what happens when one mapping’s output feeds another. Equality asks whether two mappings pair every input with the same output. Higher-order functions ask what happens when a mapping’s input or output is itself a mapping. Keep “a function is a mapping, and evaluation applies it” clear, and the rest of the exercises become variations on one idea rather than four separate topics.
Where to go next
-
Composition: one function’s output feeding the next
- what happens when evaluation’s output becomes another function’s input.
-
Equivalence: are two expressions the same for every value?
- the question of whether two mappings pair every input to the same output.
-
Mathematical shorthand: the symbols that are just words
-
a decoder for the
∈,→, andf : S → Tnotation this article uses.
-
a decoder for the
-
Algebra you forgot, and why it’s the on-ramp to lambda calculus
- the mapping view of a function, placed in its wider algebraic context.