7 Writing your model’s equations
Once you’ve sketched the diagram, you need to turn the arrows into equations. This is a technical skill, and, like most technical skills, it has a well-worked-out set of conventions that most people never learn explicitly. Edwards & Auger-Méthé (2019) set these out clearly for ecology, and this chapter summarizes their advice. I recommend you just go to their paper and read that in full first.
Check your understanding against the key papers from your field you identified earlier. They should be following the disciplinary convention, which you can emulate. However, be careful, not all published work is perfect. So notice differences in notation with other papers, or where you think the notation is not clear.
7.1 Define every symbol, immediately
The single biggest source of unreadable equations is an undefined symbol. A famous equation like E = mc² only means something because everyone already knows what E, m and c stand for; your equation doesn’t have that luxury. Define every symbol the moment it first appears, as part of the same sentence, using a “where…” clause immediately after the equation. Don’t make the reader hunt back through the paper or wait for a table. If your model has enough moving parts that this gets repetitive, add a notation table — but even then, figure and table captions should stand alone, so define the relevant symbols there too.
7.2 Use case and font consistently
A handful of typographic conventions that will help:
- Italicise scalar symbols (a, not a) — this is what distinguishes a mathematical symbol from ordinary text.
- Bold, upright Roman for vectors (lowercase, e.g. x) and matrices (uppercase, e.g. X).
- Upright Roman for functions (sin, log, ln), units (km/hr), and derivatives (d, not italic d).
- Uppercase for random variables, lowercase for their realised values — X is the random variable, x is the value you actually observed.
- Uppercase for variables, lowercase or Greek for parameters and constants. In the Ricker model, R = αSe^(−βS), R and S are variables and α, β are parameters — the case tells you which is which before you’ve even read the definitions. This is the same variable/parameter distinction from the terminology section earlier in this guide, just carried through into notation.
7.3 Index with subscripts, not with a second base letter
Use subscripts to index a quantity across a dimension: B_t for biomass in year t. The trap is reusing the same base letter for two different kinds of index — B_t for year and B_s for site both collapse to a bare B the moment you need to talk about both at once. Use a genuinely joint index instead (B_st), and keep an index consistent on both sides of an equation. Inside a summation, don’t let the index you’re summing over collide with an index used elsewhere in the equation: sum over a fresh dummy letter (k), not one that’s already doing another job (i).
7.4 Be careful with superscripts
Reserve superscripts for powers, transposes (X′ or Xᵀ), or steady states (*X**). A superscript index — B^t meaning “biomass indexed by t”, rather than “biomass to the power t” — is ambiguous on the page. If you need a second index, find another subscript position or another letter.
7.5 Avoid multiletter symbols
A label like SSB is fine as an acronym in prose, but as a mathematical symbol it’s ambiguous: nothing in the notation says whether you mean a single quantity or S × S × B. Use a single letter for anything that’s going to appear inside an equation and be manipulated algebraically.
7.6 Fully define your probability distributions
“x ~ N(μ, σ²)” isn’t fully specified until you say whether the second parameter is a variance or a standard deviation — conventions differ across fields and software, and readers will guess wrong more often than you’d expect. State the parameterisation explicitly, and state the domain too (x > 0, for instance), since that’s often exactly the information a reader needs to check your model makes sense.
7.7 Write the equations, not just the code
Some authors skip equations altogether and publish only the model code. This commonly occurs in statistical modelling, commonly with authors who are less familiar with quantitative methods. As a modeller in training I encourage you to write the equations, however.
The reason we write the equations is that they are timeless, whereas code is not. Software packages change and get updated, changing the meaning of the code. A clearly written equation is reviewable and citable independently of any particular language or package version.
You can present them as code as well as the equations when you think it will be clearer for the audience to understand.
7.8 A quick-reference table
Table 1 of Edwards & Auger-Méthé lists the conventional meanings that most readers will already assume for common letters. Following these conventions, or explicitly stating where you depart from them, saves your reader a great deal of guessing:
| Symbol | Conventional meaning |
|---|---|
| i, j, k | indices |
| n, N | sample size |
| μ | mean |
| σ | standard deviation |
| ε | error or noise term |
7.9 Revisit your notation early
Notation is much cheaper to change on day one than after it’s propagated through several papers and a large codebase. Once you’ve settled on a model structure worth keeping, take an afternoon to check your notation against the guidance above and tidy it up — it’s a small cost early and a large one late.