Using a function to describe something real
The modelling cycle, and how to judge where a model stops telling the truth.
A function used to describe something in the world is called a model. It is never the thing itself. A model of a growing plant is a rule that agrees with the measurements closely enough to be useful, over some stretch of time, for some purpose.
Here is a model built from two measurements and then tested against the rest. Run it before reading on.
Change the model to 4 + 0.6 * d and run it again. The early errors get worse and the late ones get better. No straight line fits the whole table.
For the first two weeks the line lands exactly on the measurements: the error column reads 0, 0, 0. By day 21 it is out by 1 centimetre, which is still close.
After that the plant slows down and the line does not. The error is 5 centimetres at day 28, 11 at day 35, and 18 by day 42, where the model predicts 46 centimetres against a measured 28. The model is not wrong everywhere; it is right on a stretch and wrong outside it, which is the normal state of affairs.
The cycle
Modelling is a loop rather than a single calculation, and an exam question that says model something is asking you to walk round it.
- Formulate. Decide what the input and the output are, with units, and choose a family of functions to try.
- Compute. Fit the numbers, then work out whatever was asked.
- Interpret. Say what the answer means in the words of the situation, not as a bare number.
- Validate. Test the model against data it was not built from. If it disagrees, say where and by how much.
- Report, or go round again. Either state the model with its limits, or change the family and repeat.
The validate step is the one that gets skipped, and it is the one that carries the marks. The run above did exactly that: the model was built from two points and then checked against five it had never seen.
Where a model stops being true
Using a model inside the range of the data it was built from is called interpolation. Using it outside that range is extrapolation, and it is where models go wrong. Push this one and watch.
Work out from the rule which day the model claims the height was zero, then check that day against the printed list.
At ten years the model predicts a plant 36 metres tall, and at day -10 it predicts a height of -6 centimetres. Neither is a rounding problem. Both are the model being asked a question it was never built to answer.
So a model needs a stated domain, and the domain comes from the situation rather than from the algebra. Three questions settle it in most cases.
- Which inputs are physically possible? Negative times, negative lengths and negative counts usually are not.
- Which outputs are physically possible? A height that goes on rising forever, or a population below zero, means the model has left its range.
- Must the input be a whole number? Numbers of people, of buses and of tickets are counted, so the graph is a set of separate dots rather than an unbroken curve, even if the formula would happily accept 2.6.
A shop's takings are modelled by pounds, where is the number of staff on duty. What is a sensible domain?
The whole numbers from 0 up to however many staff the shop actually has, perhaps . Staff are counted, so 3.5 is meaningless, and negative values are impossible. There is also an upper limit that the algebra knows nothing about: the model claims a thousand staff would bring in 45,200 pounds, which the shop cannot support.