reference <- 6.239
approximation <- 6.24
absolute_error <- abs(approximation - reference)
relative_error <- absolute_error / abs(reference)
absolute_error[1] 0.001100 * relative_error # percent[1] 0.01602821Meeting 1: Find and measure error
Start with a real failure
NASA’s Mars Climate Orbiter was lost after ground software used English units while onboard software used metric units. Before we discuss any floating-point arithmetic, ask: Would a more precise computer have fixed that problem? Why or why not?
Errors can enter at different stages:
| Type | Example | What to check |
|---|---|---|
| Data | An instrument reports the wrong temperature | Calibration and source quality |
| Model | We omit an important way a disease spreads | Assumptions and validation against observations |
| Implementation | One program supplies pounds while another expects newtons | Code, units, and interface tests |
| Numerical | A finite time step approximates continuous change | Precision and sensitivity to the method or step size |
The last category is our main coding focus, but fixing numerical error cannot repair a wrong model or incorrect units.
How large is an error?
Suppose the reference value is \(6.239\), but we report \(6.24\). Predict the difference before running R.
\[ \text{absolute error}=|\text{approximation}-\text{reference}|, \qquad \text{relative error}=\frac{\text{absolute error}}{|\text{reference}|}. \]
The relative error is undefined when the reference value is zero. Multiply it by 100 to express it as a percentage.
Which measure is easier to interpret if the number represents meters? Which helps compare errors for values measured on very different scales?
Why does 0.1 + 0.2 surprise us?
Predict whether the final line is TRUE or FALSE:
0.1 + 0.2[1] 0.30.3[1] 0.30.1 + 0.2 == 0.3[1] FALSER prints a rounded display. Ask it to show more digits:
sprintf("%.17f", 0.1 + 0.2)[1] "0.30000000000000004"sprintf("%.17f", 0.3)[1] "0.29999999999999999"(0.1 + 0.2) - 0.3[1] 5.551115e-17Most decimal fractions cannot be represented exactly with a finite number of binary digits. The computer stores nearby values; the difference here is tiny, but exact equality sees it.
When our question is whether two computed values are close enough, choose a tolerance appropriate to the scale of the problem:
tolerance <- 1e-12
abs((0.1 + 0.2) - 0.3) < tolerance[1] TRUEThis tolerance is suitable for this small arithmetic example; it is not a universal threshold for every model or unit. R also provides all.equal() for approximate comparisons.
Does the order of subtraction matter?
Try these two expressions before reading the output. In exact arithmetic, both are zero. R evaluates each one from left to right:
9.1 - 9 - 0.1[1] -3.608225e-169.1 - 0.1 - 9[1] 0On our R setup, the first leaves a tiny negative remainder (about \(-3.6\times10^{-16}\)), while the second gives exactly zero. The intermediate calculations round differently, even though the expressions are algebraically equivalent. Which error measure can we use when the correct answer is zero: absolute or relative error? Would either result matter if these were measurements in meters?
Can tiny errors accumulate?
Our simulations have used a vector of times made with seq(). What might happen if we repeatedly add \(0.1\) instead? Predict whether both methods below give exactly 10,000.
number_of_steps <- 100000
delta_t <- 0.1
time_by_addition <- 0
for (i in 1:number_of_steps) {
time_by_addition <- time_by_addition + delta_t
}
time_from_step_number <- number_of_steps * delta_t
time_by_addition[1] 10000time_from_step_number[1] 10000time_by_addition - time_from_step_number[1] 1.884837e-08The accumulated difference is small here. The general lesson is to measure the effect, not to assume every floating-point difference matters. When time is determined by the step number, calculating it from that number avoids repeated addition of the time step.
Meeting 2: Test the limits of a computation
Finite range: overflow and underflow
A computer stores numbers within a finite range. Predict the two results:
1e308 * 10[1] Inf1e-300 / 1e100[1] 0In ordinary R numeric arithmetic, the first becomes Inf (too large) and the second becomes 0 (too small to represent here). Both should trigger questions if they appear unexpectedly in a simulation. In ESA’s account of Ariane 5 Flight 501, a value exceeded the capacity of a converted representation; that was not the same mechanism as 0.1 + 0.2.
Order of arithmetic can matter
Our \(9.1\) subtraction produced a tiny discrepancy. Mathematically, \((a+b)+c=a+(b+c)\) too—but finite precision can make the difference much larger. Predict these R results:
a <- 1e16
b <- -1e16
c <- 1
(a + b) + c[1] 1a + (b + c)[1] 0Why can the 1 be lost in one order? This is another consequence of finite precision. The textbook also discusses adding small quantities before large ones when feasible.
A finite-step simulation is also an approximation
For the Module 2.2 example, \(dP/dt=0.1P\), \(P(0)=100\), and \(t=8\) hours. We know the analytical value \(100e^{0.8}\). Repeating the Euler update for a step of length \(\Delta t\) gives
\[ P_{Euler}(8)=100(1+0.1\Delta t)^{8/\Delta t}. \]
Before running the code, predict what happens to the error as we shorten the step:
delta_t_values <- c(1, 0.5, 0.1, 0.01)
exact_population <- 100 * exp(0.1 * 8)
euler_population <- 100 *
(1 + 0.1 * delta_t_values)^(8 / delta_t_values)
comparison <- data.frame(
delta_t = delta_t_values,
euler_population = euler_population,
absolute_error = abs(euler_population - exact_population)
)
exact_population[1] 222.5541comparison delta_t euler_population absolute_error
1 1.00 214.3589 8.19521185
2 0.50 218.2875 4.26663401
3 0.10 221.6715 0.88257113
4 0.01 222.4651 0.08894456The error here mostly comes from approximating continuous change with finite steps, not from the tiny storage error in 0.1. We saw this in Module 2.2; now we have names and measurements for it.
What would make you trust a result more?
For one of our growth, predator–prey, or SIR simulations, propose three checks. Consider units, conservation or other invariants, a different time step, and whether the assumptions fit the question. What would each check reveal—and what could it not reveal?