Hello. In the previous lesson, you translated deterministic workflow descriptions into equations such as a prompt-token total or a context allowance. An equation describes one relationship; a function gives that relationship a name and makes its input-output behavior explicit.
This is a foundational move for reading AI and ML mathematics. Papers and system specifications constantly name transformations: a cost function, a scoring function, a model function, or a routing function. Today you will learn to read that notation as a precise instruction: provide a particular input, apply a rule, and obtain one output.
A function is a named rule
A function is a rule that assigns exactly one output to each allowed, complete input.
The word complete matters. A context manager can reliably calculate an allowance only if all quantities that affect it are supplied or held fixed. Likewise, a model can calculate a score only after it has the inputs required by its scoring rule.

Think of the machine in the image as a named workflow component. It has:
- an input, the value or values supplied to it;
- a rule, the operations performed by the component;
- an output, the result produced by that rule.
For the rule “multiply the input by , then add ,” we could name the machine :
Read this aloud as:
“ of equals four plus seven.”
The symbol is the name of the function. The inside the parentheses is the input placeholder. The expression is the rule for producing the output.
Crucially, does not mean “ multiplied by .” The parentheses indicate that is being given to the function .
A valid function may send different inputs to the same output. For example, a rule that rounds a token count to the nearest thousand could map both and to . That is fine. The forbidden situation is one input producing two conflicting outputs under the same rule.
Evaluating with function notation | Functions and their graphs | Algebra II | Khan Academy
Watch Khan Academy’s “Evaluating with function notation.” It establishes the function-machine idea and then demonstrates the substitution process used to evaluate a function.
Watch the core idea for the meaning of a function as a rule that accepts an input and returns one output. Then skip to numeric evaluation, where the instructor substitutes particular values into a formula. Focus on the distinction between the general rule f(x) and a specific evaluation such as f(7).
Reading function notation in a workflow model
Return to the context-manager rule from the last lesson. Suppose these deployment settings are fixed:
- model context limit: tokens;
- system prompt: tokens;
- safety reserve: tokens.
Let be the number of tokens in the user message. Let be the retrieved-context allowance produced when the user message has tokens.
Simplifying the fixed quantities gives:
This says:
The function takes a user-message token count as input and returns the remaining number of tokens available for retrieved context.
Here is how to parse each part:
| Notation | Meaning |
|---|---|
| The name of the allowance function | |
| An input placeholder: user-message tokens | |
| The output of the allowance function for input | |
| The calculation rule that produces that output |
The definition
is general: it describes what the context manager does for any permitted user-message size .
Evaluating the function
To evaluate a function means to calculate its output for a specified input.
Suppose a request has:
tokens in its user message. Substitute everywhere the placeholder appears:
The complete interpretation is:
For a user message of tokens, the workflow allows up to tokens of retrieved context.
Notice the difference between these statements:
The first is the rule. The second is one evaluated result from that rule.
A dependable evaluation procedure is:
- Identify the requested input inside the function parentheses.
- Replace every occurrence of the input placeholder in the rule with that value.
- Perform the arithmetic, respecting parentheses and order of operations.
- State what the resulting output means, including its units.
In this example, the output is measured in tokens. That unit check is useful: an allowance in dollars or seconds would signal that you had used the wrong rule or quantity.
Inputs, fixed settings, and parameters
The function treated the system-prompt size, model limit, and safety reserve as fixed. That was a deliberate modeling choice. During a particular deployment, those values may indeed remain unchanged while user-message size varies from request to request.
But suppose the safety reserve also changes by task. Then is no longer a complete description unless you specify which reserve is being used. The more complete function is:
where:
- is user-message tokens;
- is safety-reserve tokens.
Now evaluate the function for a -token user message and a -token reserve:
The comma means the function receives two inputs. Their order and meaning are part of the definition:
means “first supply user-message tokens, then supply reserve tokens.”
This connects directly to the distinctions from the first lessons:
- An input varies across evaluations of a function.
- A parameter is a setting that controls the rule. It may be held fixed for a while, then changed to define a different configured behavior.
- A constant is a value treated as fixed within the current model.
- An output is what the function returns after the calculation.
For an input-cost function, both token count and price might vary:
where is the number of input tokens and is the price in dollars per token. If:
then:
The output is dollars. The units validate the calculation:
A system specification that writes only is usually assuming that the price has been fixed as a configuration parameter. That assumption may be perfectly reasonable, but function notation makes it worth asking: which quantities are actual inputs, and which ones have been held constant?
Functions need not be algebraic formulas
A function is not necessarily an equation. It can also be a lookup table, a configuration rule, or a program procedure, as long as every allowed input has one unambiguous output.
Suppose a harness has three approved retrieval tiers. Let return the number of documents selected for tier .
| Retrieval tier | Documents selected |
|---|---|
| low | 2 |
| standard | 5 |
| high | 8 |
From this table:
This is a function because the input “standard” has exactly one output: documents. The inputs do not need to be numbers. They can be labels, categories, prompts, files, or structured system states.
The key question is always:
Once the complete input is specified, does this rule determine one output?
For AI workflows, this question exposes incomplete specifications. If a routing rule says that the same score can send a request to either a cheap model or an expensive model, the rule is not yet deterministic. Perhaps it is missing a tie-break condition, a latency measurement, or a random selection step. You would either add the missing input or explicitly model the randomness later in the course.
Function notation in ML papers
You will often see a compact expression such as:
Read it in layers:
- is the input data, perhaps features, an embedding, or a prompt representation.
- is the model’s transformation rule.
- is a collection of model parameters.
- is the model’s predicted output.
The subscript in says that the function is governed by a particular parameter setting . With those parameters held fixed, giving the model input produces the output .
At this stage, do not treat this notation as mysterious ML-specific machinery. Structurally, it is the same idea as:
Both describe a named transformation applied to an input. The ML expression simply represents a much more complicated rule, whose parameters will eventually be trained or tuned.
One more distinction is useful:
is a function definition. To evaluate it at , replace with :
Evaluation asks for the output produced by a known input. The reverse task—starting with an output and searching for possible inputs—is called solving, and it can have more than one answer. For now, keep the direction clear: evaluation starts from an input and computes an output.
A compact reading habit
When encountering a function in a paper, notebook, or harness specification, pause and translate it into a sentence.
For example, for
say:
“The cost function takes token count and price per token , then returns total cost.”
For
say:
“The model with parameters takes input and returns prediction .”
This verbal translation prevents two common errors:
- treating the parentheses in as multiplication;
- overlooking an input or parameter that the output actually depends on.
Wrap-up
A function is a named input-output rule. Its central requirement is precise: each complete allowed input must produce one output.
You can now:
- read as “the output of function when given input ”;
- distinguish a general rule, such as , from a specific evaluation, such as ;
- evaluate a function by substituting the given input everywhere the placeholder appears;
- recognize when a changing quantity should be an additional input rather than an unstated assumption;
- interpret compact ML notation such as as a parameterized input-output mapping.
Next, you will use summation and product notation to express repeated calculations compactly—for example, total cost across many calls or the combined contribution of many workflow steps.
Can't find a good explanation? Sign up and we'll make it for you
Sign up