With typed pseudocode in hand, you can read what a program does. One of the most common things programs do is stand in for some part of the world, so that we can ask questions about it. This section follows that work through its three stages: building a model, which means deciding what to leave out; running it, which often involves many interacting parts and some randomness; and judging it, which means deciding how far its answers can be trusted. Most mistaken claims about models come from skipping one of these stages.

Building a model#

A model is a simplified representation of a system that keeps the features relevant to a question. A simulation runs a model over time, so the model is the description and the simulation is that description in motion. Simulations are valuable when the real thing would be too costly or dangerous to test directly. City planners can try out a bus lane in software without closing a street, and engineers can run virtual crashes of many car designs before destroying a single prototype. A simulation differs from a database, which stores past observations, because it generates behavior from rules. It also differs from an experiment, because nothing in the real system has been measured. This is why a simulation's results still need validation against reality, and why a virtual crash test can narrow down the designs without making physical testing unnecessary.¹

Simplifying is what makes a model a model, so every model leaves out details. A simulation of how a disease spreads through a school needs each student's contacts and infection status and has no use for hair color. Adding detail may increase realism, but it also raises computational cost, sometimes steeply, and that cost can limit what is feasible. Weather forecasting shows the trade-off clearly: a grid of cells 1 kilometer wide captures local storms that a 25-kilometer grid misses, yet a daily forecast may have to use the coarser grid, since a forecast that arrives after the weather has happened helps no one. Removing detail has its own danger, because the detail removed might be the one that matters. A simulation of fire spreading through a forest can reasonably replace individual leaves with cells of trees that share a fuel level, but it can't discard the distance between trees. More detail isn't automatically better, and neither is less. A detail belongs in a model when it matters to the goal and is worth its cost, so a model should be judged by whether it answers its question well enough. A simple enrollment forecast that ignores some factors isn't useless for that reason alone.

Running a model#

Some systems are hard to describe from above with a single equation, because what happens overall depends on many individuals reacting to one another. An agent-based model takes the opposite approach. It gives many simple agents local rules, runs them together, and lets large-scale patterns appear. Those patterns can be ones that no rule states, which is called emergence.² Simulated drivers who only speed up when the road is clear and slow down near another car produce traffic jams that travel backward along the road, although no rule mentions congestion. Birds that respond only to their neighbors form flocks, and ants that follow and reinforce scent trails form a main path to food. No central agent directs any of this, and no ant has calculated the route. Emergence also warns against reading a group's pattern back onto its members. In a housing model in which each household wants only a few similar neighbors, neighborhoods can become far more segregated than any household preferred, so the outcome doesn't show that households want extreme segregation.

Agents and other simulated events often need to behave unpredictably, as when customers arrive at random times. Computers supply this with pseudorandom numbers, which look random but are produced by a deterministic algorithm from a starting value called a seed. Because the values differ from run to run, two students running the same disease simulation can get different peak infection counts without either program having an error. One run is a single sample of what could happen, so simulations are run repeatedly, and the results describe a range of likely outcomes. Report the range, and not the result of one run. Fixing the seed makes a run reproducible, which is useful for debugging, since you can recreate exactly what went wrong. It doesn't remove uncertainty about the real system or make the predictions more accurate. Probabilities from a simulation also hold only under the model's assumptions.³ If a bridge fails in about 200 of 10,000 simulated runs, the 2% figure describes the model and doesn't mean that the real bridge will fail in exactly 2 of every 100 uses.

Judging a model#

That caution about assumptions leads to the larger question of when a model's output should be believed. The main test is to try the model on data not used to build it. A model can fit existing data so closely, noise included, that it fails to predict anything new, a problem called overfitting.⁴ A model that matches last year's course grades nearly perfectly and then does poorly on this year's students has probably done exactly this. High accuracy on the training data therefore proves little, and a claim of 99% accuracy measured on the data used to build a model doesn't show how it will perform on new cases. The standard practice is to build on part of the data and evaluate on the rest: with records for 1,000 patients, build on 800 and evaluate on the other 200. A climate model built on data through 2015 earns more confidence by predicting 2016 onward than by any amount of adjustment, and adding variables until it matches the past exactly only increases the risk of overfitting. Rerunning a model on its original data checks only that it is repeatable, and printing more decimal places adds precision without adding validity.

Even a well-validated model has limits on where it applies, because it knows only the conditions it was built from. Extrapolation means predicting beyond the range of the data used to build a model, and it is unreliable because the observed pattern may not continue.¹ A model of height built on children from 5 to 12 works well within those ages and gives an absurd height for an adult. A straight line through ten years of rising enrollment says little about enrollment 50 years ahead. The range can be one of conditions as well as numbers: a model of a town's summer electricity use that is applied to winter has also stepped outside its data. Interpolation, by contrast, stays within the range of the data, so it is generally the safer kind of prediction.

Every stage of this work has depended on data, whether to build a model or to check it. The next section turns to how that data is gathered in the first place.

• model: a simplified representation of a system that keeps the features relevant to a question
• simulation: a model run over time
• agent-based model: a model in which many simple agents follow local rules
• emergence: a large-scale pattern that arises from local interactions without any rule stating it
• pseudorandom numbers: numbers that appear random but come from a deterministic algorithm
• seed: the starting value for a pseudorandom sequence; fixing it makes a run reproducible
• overfitting: fitting existing data so closely, noise included, that prediction fails
• extrapolation: predicting beyond the range of the data used to build a model
• interpolation: predicting within the range of that data

Practice: practice questions for 0002.a

1. MWC2, Estimation: fitting models and overfitting. ↩ ↩2

2. LAI 516, Media: NetLogo: agent-based modeling. ↩

3. MWC1, Dice: classes, instances, randomness, and repeated runs. ↩

4. MWC2, Classification: Features: train/test splits, evaluation, feature engineering, and data cleaning. ↩