Two ways to say 'how wrong'
You already know from the last two guides that every numerical result is an approximation, and that error leaks in from modeling, data, truncation, and round-off. The natural follow-up is to actually measure the gap. There are two honest ways to do it, and the whole craft of reporting results lives in choosing the right one. Let x be the true value you wish you knew, and x~ the number your computation actually produced.
The first way is the plainest: the absolute error is the distance |x~ - x|, measured in the very same units as the quantity itself. A bridge span computed as 5.03 metres against a true 5.00 metres has absolute error 0.03 metres. It is concrete and tangible — but it carries a blind spot. An error of 0.03 is laughably tiny beside a true value of a million, and a catastrophe beside a true value of 0.001. Absolute error simply does not know whether the thing it is measuring is big or small.
The second way fixes exactly that blind spot. The relative error scales the gap by the size of the answer: |x~ - x| / |x|, with x nonzero. Now 0.03-out-of-a-million is 3e-8 (superb) while 0.03-out-of-0.001 is 30 (a disaster), and the number itself tells you which. Being a pure ratio, relative error is dimensionless and scale-free — it reads the same whether you measured in metres or millimetres — which is why it is the natural language whenever magnitudes roam over many orders. Multiply by 100 and you have the familiar percentage error.
Measuring it in practice, and in higher dimensions
There is an awkward catch hiding in both definitions: they need x, the true value — the very thing you do not have. If you knew the exact answer you would not be computing an approximation. So in real life you almost never measure the true error directly. Instead you estimate it. One cheap and ubiquitous trick lives inside iterative methods: watch the change between successive iterates, |x_{n+1} - x_n|, and use it as a practical stand-in for the unseen error. That single quantity is what most stopping criteria actually test.
When the answer is not a single number but a vector or a function — a solution of A x = b, a whole sampled curve — 'distance' needs a norm. The absolute error becomes ||x~ - x|| for some chosen norm: the 2-norm ||x~ - x||_2 is the familiar Euclidean length of the error vector, while the max-norm reports the single worst component. The relative error then divides by the norm of the truth, ||x~ - x|| / ||x||. The choice of norm matters: a result can look excellent in the 2-norm (small on average) yet have one ugly spike that only the max-norm reveals.
Significant digits: error you can read off
Relative error has a wonderfully human translation: significant digits. These are the digits in a number that actually carry trustworthy information, counted from the first nonzero digit onward. In 0.004520 the significant digits are 4, 5, 2, and the trailing 0 — four of them; the leading zeros only mark the decimal point and do not count. Significant digits are the everyday way of saying how precisely something is known.
Here is the bridge, the single most useful rule in this guide: agreeing to d significant digits is essentially the same as having relative error around 10^(-d). More carefully, x~ matches x to about d significant figures when |x~ - x| / |x| is roughly 5 * 10^(-(d+1)) — but the clean working version, 'relative error near 10^(-d) means about d trustworthy digits', is what you will use every day. So three correct figures is a relative error near 1e-3; six figures, near 1e-6.
relative error significant digits 1e-1 ~1 1e-3 ~3 1e-6 ~6 1e-16 ~16 (double-precision ceiling) d digits <--> relative error ~ 10^(-d)
That last row is not a coincidence. Standard double-precision arithmetic stores numbers to a relative precision of about 1.1e-16, so no double-precision result can ever be trusted to more than roughly 15-16 significant decimal digits. That is a hard ceiling set by the hardware, not by your algorithm. Worked example: approximate pi by 22/7 = 3.142857... against pi = 3.141592...; the absolute error is 0.001264, the relative error 0.001264 / 3.141593 = 4.0e-4 (about 0.04%), which tells you 22/7 is good to roughly three significant digits — exactly as you read the printout.
When the digits lie: where your significance goes to die
Now the honest part, and the reason this guide is more than bookkeeping. Printing 16 digits does not mean 16 are correct. A program can proudly display 3.14159265358979 while only the first six digits are real and the rest are pure noise. Two distinct effects silently eat your significant digits, and a careful person learns to smell both.
The first is catastrophic cancellation. Subtract two numbers that are nearly equal, and the leading digits — the ones they agree on — cancel to zero, leaving only the low-order digits where round-off noise was already lurking. The noise is promoted into the most significant position of the answer. Computing 1 - cos(x) for tiny x is the classic trap: cos(x) rounds to 0.9999999..., the subtraction wipes out the agreeing digits, and the true value near 5e-9 keeps only a couple of honest figures. Rewriting it as 2*sin^2(x/2) sidesteps the subtraction and rescues the digits — a reformulation, not a fancier computer. You will meet this in depth in the floating-point rung.
The second effect is deeper and not your code's fault at all: ill-conditioning. Some problems are inherently sensitive — a tiny wobble in the input forces a large swing in the true answer — and the condition number measures exactly how much. A rough but unforgettable rule: a problem with relative condition number around 10^8 amplifies input error by about 10^8, so it spends roughly 8 of your ~16 double-precision digits before any algorithm even runs. You start the race having already lost half your accuracy, and no clever coding buys it back, because the sensitivity lives in the problem, not the method.
Reporting like a professional
Putting it together, a result without an error statement is barely a result at all. The grown-up habit is to report a number alongside an honest claim about how many of its digits you stand behind — and to be explicit about whether that claim is absolute or relative. Here is the small discipline that turns a printout into something trustworthy.
- Decide your currency first. Is the natural tolerance fixed in physical units (use absolute error) or does the answer span many magnitudes (use relative error)? If the answer can cross zero, plan a mixed tolerance |error| / (1 + |x|) so nothing explodes.
- Estimate the error without the true value. Use the iterate-to-iterate gap |x_{n+1} - x_n|, a residual check, or a finer-grid comparison — an a-posteriori estimate from quantities you can actually see.
- Convert to digits. A relative error near 10^(-d) means roughly d trustworthy significant figures — that is how many you are entitled to print.
- Discount for the hazards. If the computation subtracted nearly equal numbers, suspect cancellation; if the problem is sensitive, subtract about log10(condition number) digits up front. Never print past your ~16-digit double-precision ceiling.
Follow this and you graduate from someone who copies whatever the screen shows to someone who knows what it means. In the next guide we turn to the other half of the story — the same big-O notation reused in two completely different ways: O(h^p) for how fast error shrinks, and O(n^3) for how fast cost grows. Error told you whether the answer is good; cost will tell you whether you can afford it.