A Computer Only Knows Numbers Approximately
Up to now we treated error as coming from the method: the step is too large, the degree too low. But beneath every method lies a more fundamental limit. A computer cannot store real numbers exactly, not even 0.1. A 64-bit float remembers only about 15 to 16 digits and rounds away the rest. Usually this tiny error stays buried and invisible, but it leaps out the moment you subtract two nearly equal numbers, accumulate a small error a million times, or meet a problem whose answer is sensitive to its input (a bad condition number). This lesson looks at the floor of numerical analysis, the very way a computer handles numbers and the error that leaks from it. It is the identity of the roundoff floor you saw in the previous lesson.
The ticks on the number line are the numbers a computer can store exactly. At first glance it looks strange: dense near 0, sparser to the right. That is because floating point writes a number as a few significant digits plus an exponent, much like scientific notation. So each time the magnitude doubles (one octave), the gap between neighboring representable values doubles too. This smallest gap is called the ulp (units in the last place). Move x and you see the ulp grow for larger numbers. It means big numbers are stored coarsely and small numbers finely. Every round-off error starts here.
Let us measure just how small that gap is, near 1. Add ε = 2k to 1 and lower k step by step. At some point 1+ε simply becomes 1. That happens once the added ε is smaller than half the representable gap above 1, so it rounds to the nearest representable value, which is 1 itself. This boundary is the machine epsilon: in float64 it is 2⁻⁵² ≈ 2.2×10⁻¹⁶, about 15 to 16 significant digits. This is not abstract talk but real arithmetic. To a computer, 1 plus a tiny number can simply be 1. It is the first proof that precision has a floor.
A single error sits around 10⁻¹⁶, so it seems safe to ignore. But 0.1 does not divide evenly in binary, so the moment it is stored it already carries a tiny error. Each time you add it, that error piles up a little too. Use the slider to raise the number of additions and watch the error from the true n/10 grow steadily. What was invisible in one step becomes clear after a few hundred, and in a computation that repeats billions of times, like a simulation, it can ruin the result. That is why numerical programmers tame this accumulation by changing the order of addition (smallest first) or using compensated summation (Kahan summation).
The scariest case is its own: subtracting two nearly equal numbers. Compute (1−cos x)/x² for small x. The true value should head to 0.5 as x shrinks. Yet the gold curve (computed naively) collapses to 0 at some point. When x is small, cos x is almost 1, so 1−cos x loses nearly all its significant digits: the leading digits match and cancel, leaving only untrustworthy trailing digits. This is catastrophic cancellation. The blue curve computes the same value rewritten as 1−cos x = 2 sin²(x/2). Since it never subtracts, it holds 0.5 all the way down. The formula is the same, but the order of computation makes or breaks the precision.
The last one is not about error but about the nature of the problem itself. Solving a system of equations means finding where two lines cross. If the lines cut across cleanly, the intersection is sharp. But what if they are nearly parallel? Nudge one line by a hair and the intersection darts far away. Use the slider to lower the slope and make the lines nearly parallel: for the same 10% nudge the solution moves more and more. This amplification factor is the condition number. A large condition number (ill-conditioned) blows a small input error up large in the answer. The frightening part is that, unlike round-off, this cannot be fixed by a better computer, because the problem itself is touchy. So good numerical analysis takes care of both a stable algorithm and a well-conditioned problem.