Functions aren't what you remember from high school
Most people learn functions as a formula: input goes in, output comes out. That is technically correct but practically useless when you are actually working with them. A function is any rule that assigns exactly one output to each input from a specified domain. The rest of the details matter far more than the basic definition. The formal definition says a function f from set A to set B is a relation where every element of A appears exactly once as an input. That means if you plug in the same value twice, you must get the same result twice. It also means you cannot have a single input mapping to two different outputs. Simple on paper. Messy in practice. I spent years dealing with piecewise definitions and implicit mappings where the domain wasn't clearly stated upfront. One specific project involved modeling a payment calculation where a fee structure changed based on transaction amount brackets. The function definition looked straightforward until I realized the boundary values were ambiguous. Was a $100 transaction charged at the lower bracket or the upper bracket? I ended up defining the function with half-open intervals like [0, 100) and [100, 500) to eliminate the ambiguity entirely. That small notation choice prevented months of disputes later.
The technical terms you should actually use are domain, codomain, range, injective, surjective, and bijective. Beginners often conflate codomain with range. The codomain is the set you declare the function maps into. The range is the subset of the codomain that the function actually hits. If your function is f(x) = x squared and the codomain is all real numbers, the range is only the non-negative reals. That distinction matters when you are composing functions or checking whether an inverse exists. Here is a counter-intuitive point most people miss. A function does not need a single algebraic formula. It can be defined by a table, a graph, a piecewise description, an algorithm, or even an oracle. The definition of function in math does not require you to write y equals something. If you can unambiguously determine the output for any given input, you have a function. Period. This comes up constantly in numerical methods where functions are implemented as lookup tables or iterative solvers rather than closed-form expressions.
How to work with functions practically
Start by explicitly stating the domain and codomain before doing anything else. Most errors in applied mathematics come from undefined or assumed domains. If you are working with a rational function, identify where the denominator is zero and exclude those points. If you are working with a logarithm, ensure the argument is strictly positive. These are not optional considerations. When checking whether a relation is actually a function, use the vertical line test for graphs and the one-to-many test for relations. A relation fails to be a function if any input produces more than one output. The square root relation y squared equals x is the classic example. For x equals 4, y can be positive or negative 2. That is a relation, not a function, unless you restrict the output to one branch. Composition of functions follows the rule f composed with g of x equals f of g of x. The order matters. Switching the order usually produces a different result. Domain restrictions compound during composition. The domain of f composed with g is the set of inputs where g is defined and where g of x falls within the domain of f. I once saw an entire analysis pipeline break because someone composed two functions without checking whether the range of the inner function fit inside the domain of the outer function. The model produced NaN values throughout and took two days to trace back to that single oversight.
Get the Full Details
Inverses only exist for bijective functions. A function must be both injective and surjective to have a true inverse. In practice, you often restrict the domain to make a function invertible. The sine function is the standard example. You cannot invert sine over all real numbers because it is periodic and repeats values. Restrict the domain to negative pi over two through pi over two and the inverse sine function works cleanly. This restriction is not a workaround. It is required by the definition.
Where the standard approach breaks down
Functions fail to model certain real-world phenomena adequately. Stochastic processes involve randomness, not deterministic assignment. A function cannot capture the idea that the same input might produce different outputs with different probabilities. When you need that, you move to probability distributions or stochastic maps, which are related but fundamentally different constructs. Multivalued functions exist in complex analysis and algebraic geometry. The complex logarithm and complex square root are examples where a single input maps to multiple outputs. Mathematicians handle these with branch cuts and Riemann surfaces. If you are working in a computational setting, you typically pick one branch and live with the discontinuity that comes from that choice. This is a well-known limitation of treating everything as a standard function. Anonymous or lambda functions in programming are another area where the mathematical definition gets stretched. They are fine for short applications but become unmaintainable when the logic inside exceeds a few operations. I recommend defining named functions with explicit type signatures whenever possible. It takes slightly more time upfront but reduces debugging time significantly downstream.
If you need a quick reference on formal function definitions and properties, the Stanford Encyclopedia of Philosophy entry on functions and the nLab page on functions are reliable resources. They are dense but accurate. For a more accessible treatment, Abbott's Understanding Analysis covers the rigorous definition with appropriate examples.
