Exercises — Module 19 (Floating-Point Arithmetic, §4.2)
Self-contained problems on this module's material — exact vs. inexact binary
fractions, the guard/round/sticky machinery of correct rounding, exponent
overflow in multiplication, Sterbenz's exactness lemma, error bounds for naive
and Kahan summation, and the non-associativity of floating-point addition. You
can work every one without the book: each states the problem in full, gives
a hint to peek at when stuck, and a worked answer sketch to check
against. Numeric answers here are reproduced by the Float you build in the lab
(or a few lines at a REPL), and they agree with hardware f64 bit for bit.
Ratings follow Knuth's scale (00–50; M = needs mathematics, ▶ = especially
instructive). Each problem cites the section of Vol. 2 (§4.2.1 / §4.2.2) whose
material it exercises. Throughout,
is the binary precision, is the
machine epsilon (the gap ), and the unit roundoff is
.
Tracking
| # | Topic | Rating | Status |
|---|---|---|---|
| 1 | Which decimal fractions are exact in binary? | 10 | ⬜ |
| 2 | ▶ Why the sticky bit is necessary for correct rounding | 20 | ⬜ |
| 3 | Overflow from the exponent sum in multiplication | 22 | ⬜ |
| 4 | ▶ Sterbenz's lemma: exact when | M25 | ⬜ |
| 5 | Error bounds for naive vs. Kahan summation | M28 | ⬜ |
| 6 | ▶ When does differ from , and by how much? | M30 | ⬜ |
Problems
1. Which decimal fractions are exact in binary? (rating 10 · cf. §4.2.1)
Problem. Give the normalized binary form (leading significand bit ) of , , , and . Which of these — and more generally which decimal fractions in lowest terms — are represented exactly by a finite binary significand, and which are not?
Hint. A number has a finite binary expansion iff, written in lowest terms , its denominator divides some power of two — i.e. is itself a power of two. Factor each denominator. Recall §1's headline fact: repeats forever.
Answer sketch. (exact), (exact), (exact). But is
not exact: has an odd prime factor , so no power of two
is a multiple of , and the expansion (block 0011
repeating) never terminates. General rule: in lowest terms is exactly
representable in binary iff for some — equivalently has no
odd prime factor. So (denominators ) are
exact, while (denominators ) are not. This is
why from_f64(0.1) stores the nearest 53-bit number to , within half a
ulp — the root of every "floating point is broken" bug report.
2. ▶ Why the sticky bit is necessary for correct rounding (rating 20 · cf. §4.2.1)
Problem. Round-to-nearest-ties-to-even needs, beyond the kept bits, a round bit (first discarded bit) and a sticky bit (OR of all bits below ). Show by a concrete example that alone is not enough: exhibit two additions with identical kept bits and identical round bit but different correct results, distinguished only by . Explain why alignment in Algorithm A makes exactly the right summary of the discarded tail.
Hint. The round bit alone cannot tell an exact tie (round bit , nothing below) from a value just above the midpoint (round bit , something below). Those two round differently when the last kept bit is even. Build both as where the tiny addend places a at the round position.
Answer sketch. Work at the scale of , where and the round position is bit (half a ulp). Compare two single correctly-rounded additions:
- : the exact sum is — round bit , sticky : an exact tie. Ties-to-even keeps the last bit even, and 's last kept bit is , so it rounds down to .
- : the addend is one representable value; the exact
sum has round bit and a nonzero bit at , so — it is
above the midpoint and rounds up to
1.0000000000000002.
Both have identical kept bits and identical round bit ; only differs,
and it flips the result. (Verified on hardware f64: the two single additions
yield 1.0 and 1.0000000000000002.) Without the sticky bit you would treat
the second case as a tie and wrongly round it down. Why suffices: RNE's
decision depends on whether the exact value is below, at, or above the
midpoint, and "above" is detected purely by "is any discarded bit below
set?" — that single OR is . In Algorithm A's alignment step A4, a small
addend shifted right by many places dumps all its bits past the round position;
collapsing every one of them into loses nothing rounding cares about, which
is why the implementation keeps a fixed guard window and ORs the rest into
sticky.
3. Overflow from the exponent sum in multiplication (rating 22 · cf. §4.2.1)
Problem. In Algorithm M the exponents simply add: . Show that can overflow (exceed the largest finite float) even when both and are comfortably inside the representable range. Characterize, in terms of the exponents, exactly when this happens, and give a concrete binary64 example.
Hint. binary64 writes normals as with ; the largest finite value is just under . The product's exponent is (about) , so two mid-range magnitudes can push the sum past the top.
Answer sketch. Since significands lie in , with the significand product in , so the result's exponent is or (a normalizing carry). Overflow occurs when this exceeds , i.e. roughly when — a condition on the sum of exponents, each of which may individually be far below the ceiling. Concretely, are both finite (well under ), yet overflows to ; likewise give (verified on hardware). So " and in range" does not imply " in range": the danger lives in the additive exponent, not in either operand. (The mirror failure is underflow when drops below ; both are why robust code scales operands or uses -domain products. The significand rounding at M3 is exact-then-round and never itself causes overflow beyond that one carry bit.)
4. ▶ Sterbenz's lemma: exact when (rating M25 · cf. §4.2.2)
Problem. Prove Sterbenz's lemma: if and are floating-point numbers of the same sign with (equivalently, within a factor of two of each other), then the exact difference is itself a floating-point number — so with no rounding error.
Hint. Assume WLOG . Both and are integer multiples of the smaller number's ulp; show is a multiple of that same ulp and small enough in magnitude to be representable at that scale (no bits below the ulp, and it fits in significant bits).
Answer sketch. WLOG take (same sign; the difference's sign is handled symmetrically). The hypothesis gives . Write where is 's exponent (ulp ) and . Since , the number has exponent or , so is an integer multiple of — the ulp of — as is . Hence is an integer multiple of : it has no bits below position . And , so needs at most significant bits above position . A value that is a multiple of and lies in is exactly representable with a -bit significand and exponent . Therefore is a float and the machine subtraction is exact. (Empirically: over random pairs with , matches the exact rational difference every time.) This benign-cancellation fact is exactly what makes the step in Kahan summation (Exercise 5) recover the lost bits precisely.
5. Error bounds for naive vs. Kahan summation (rating M28 · cf. §4.2.2)
Problem. Let be floats summed left to right. Using the model — each addition returns the exact sum times with — bound the absolute error of naive summation, then of Kahan compensated summation, and show the Kahan bound is essentially independent of .
Hint. For naive, the -th partial sum picks up one factor ; expand the product and keep first order in , bounding each partial magnitude by . For Kahan, the correction removes each step's rounding error to first order (that is the point of the algorithm), leaving only a second-order residue on top of a single term.
Answer sketch. Write , . Unrolling, the computed total is , and since with ,
The naive error grows linearly in (worst case), which is why summing
a hundred thousand times drifts to 10000.000000018848 instead of
10000. For Kahan, the invariant is that holds, to first order, exactly the
rounding error dropped by the previous (proved by
Sterbenz's lemma, Exercise 4: when , is exact, so is the true lost part). Feeding back cancels each step's leading
error, leaving
an bound whose -dependence is pushed to second order — effectively
constant. Empirically Kahan lands on 10000.0 to the bit, and on the adversarial
(ten thousand ones) it recovers 10000 while
naive returns 0 — every 1 was swamped and rounded away, but Kahan's held
each lost 1 and fed it back. Cost: about the flops, hence a choice,
not a default.
6. ▶ When does differ from ? (rating M30 · cf. §4.2.2)
Problem. Floating-point addition is commutative but not associative. Characterize when and give different results, exhibit a concrete triple that differs, compute the exact difference, and bound how large the discrepancy between the two groupings can be.
Hint. Each grouping is correctly rounded at every step, so each equals the true sum times a product of two factors. They differ exactly when the two roundings the groupings perform are not the same — e.g. one grouping forms an intermediate that rounds a bit away that the other grouping preserves. Use , , and trace both.
Answer sketch. Let (half a ulp at ). : the
first add is an exact tie, rounds to even ; then ties again
. But : exactly
(no rounding), and 1.0000000000000002 exactly. So
verified on hardware f64. When do they differ? Using TwoSum, each addition
with the exact
rounding error; carries the errors of forming then adding ,
while carries the errors of forming then adding . The two
agree iff those accumulated errors coincide; they differ precisely when at least
one grouping performs an inexact rounding the other avoids (as above: is
inexact and destructive, is exact). How much? Each grouping equals
with , so
i.e. a couple of ulps of the operands — small in absolute terms, but (as when
nearly cancels) potentially unbounded in relative terms. The
practical moral of §6/§8: you may not freely reorder floating-point sums, and
-ffast-math reorderings can change results — the discrepancy is exactly this
non-associativity.
Your solutions
Use this space to log your own work — a restated problem, your approach, and how it compared with the sketch above.
Exercise N (rating RR)
Approach. Answer / proof. Compared with the sketch: what you did differently, what you missed.