Rounding: the rules, and what they cost

Rounding looks like the one corner of arithmetic with nothing to argue about. Pick a value and watch six rules disagree about it; then round the same number in two steps instead of one, and watch the answer change.

Loading interactive simulation...

Half-to-even is not a more accurate rule, it is an unbiased one 🖖

At a tie the value is exactly between two neighbours and no rule can be right; the only question is which way to be wrong. The school rule always goes up, which is easy to teach and easy to check, and its cost is that it is wrong in the same direction every time. Load a column of ties and press half-up: the total lands half a unit per value above the truth β€” 1,000 too high on 2,000 values, 3,200 too high on 6,400 β€” with no scatter at all, because nothing about a rule that never varies is random. Half-to-even sends a tie to whichever neighbour is even, so 2.5 goes down to 2 while 3.5 goes up to 4. Across a column that is not conspiring, that alternates and the errors cancel instead of stacking. IEEE 754 made it the default for floating-point arithmetic and most accounting standards ask for it, and neither did so because it is more accurate. On any single number it is sometimes worse. It is unbiased across many, which is a different property and the one that matters when there are many.

Rounding twice is a different operation from rounding once 🖖

Take 2.45 to a whole number: what follows the point is less than a half, so the answer is 2. Now do it in two moves. To one decimal place, 2.45 is a tie and becomes 2.5; and 2.5 to a whole number is 3. Both moves obeyed the rule, and the answers are 2 and 3. What happened is that the first rounding manufactured a tie that was not there β€” the original value sat safely below the halfway mark, and after one step it was sitting exactly on it, leaving the second step to guess. Sweep every two-decimal value up to 1,000 and the stopover changes the answer for 5.00% of them: every value whose hundredths run from 45 to 49, which is 5 in every 100. This is why a currency conversion, a tax calculation or a chain of unit conversions specifies where the rounding happens. Not because anyone doubts the arithmetic β€” because "round at the end" and "round at each step" are two different calculations wearing the same clothes.

A biased error grows with the count; a fair one grows with its square root 🖖

Switch the column to ties and drag its length. Half-up draws a straight line: every value contributes half a unit in the same direction, so the drift is half the count, forever, with no scatter. Half-to-even draws something that wanders β€” up a little, back down, across zero and out the other side. Measured across 2,000 different columns, the typical size of that wander is half the square root of the count: about 5 at a hundred values, 20 at sixteen hundred, 40 at sixty-four hundred. That is the signature of a random walk, and it is the whole practical difference. At sixty-four hundred values the biased rule is out by 3,200 and the fair one by about 40, and the ratio between them keeps widening with every row added, because one is growing like the count and the other like its square root. Switch to ordinary amounts and the same thing happens quietly: ties are rare there, 11 in 1,000, so most of the drift comes from ordinary rounding and both half-rules land within about 8 of the true 98,351.63. Then try floor on the same column and it is 486 short β€” because floor takes something from nearly every value, not only from the ties.

Problems solved in full

  1. Rounding 1,000 amounts to the nearest whole unit with a 98,351.63 true total 7 steps

    A shop rounds each of 1,000 amounts to the nearest whole unit and adds them up. The true total is 98,351.63. Work out what the rounded total comes to under each rule, and decide which one the shop should use.

    1. Settle the rule before the column means anything. Take 2.5. Half-up sends it to 3. Half-to-even sends it to 2, because 2 is the even neighbour.

    2. Check that half-to-even alternates rather than always going down: 3.5 goes to 4 under both rules, because this time the even neighbour is the one above.

    3. Now the column. Of the 1,000 amounts only 11 sit exactly on a tie, so the two half-rules agree on 989 of them and can differ by at most 11 β€” one unit per tie.

    4. Add the rounded values. Half-up gives 98,360, which is 8.37 above the truth. Half-to-even gives 98,354, or 2.37 above. The 6 between them came from those 11 ties.

    5. Most of that drift is not the ties at all β€” it is ordinary rounding, which on 1,000 ordinary amounts is about as likely to go either way. To see the rules themselves rather than the noise, switch the column to ties, where every value is one: half-up is then 500 too high and half-to-even is 6 out.

    6. Try floor on the original column for contrast: 97,866, which is 486 short. Floor takes something from nearly every value instead of only from the ties, so its drift does not need ties to accumulate.

    7. Which rule to use therefore depends on what is being protected. For a single receipt any half-rule will do, and the difference is never more than half a unit. Across a ledger, only a rule with no preferred direction leaves the total where it started.

    Answer

    98,360 under half-up, 98,354 under half-to-even, 97,866 under floor, against a true 98,351.63. The shop should use half-to-even β€” not because it is more accurate on any one amount, where it is sometimes worse, but because its errors have no direction and so do not accumulate. Half-up is wrong by half a unit on every tie it ever meets, upward, without exception.

  2. 1.005 to two places, and the tie that is not one 7 steps

    Round 1.005 to two decimal places. Work out what the machine is really holding when you type that, then decide whether a spreadsheet answering 1.00 has made a mistake.

    1. As a decimal it is a tie: 1.005 stands the same distance from 1.00 as from 1.01, so half-up sends it upward and the panel prints 1.01.

    2. The machine is not holding a decimal. A double is a sum of powers of two, and 0.005 is one two-hundredth, whose denominator carries a 5Β² that no power of two can supply. The binary expansion never ends.

    3. What gets stored is the nearest double, and it sits below 1.005 by about 1.07 Γ— 10⁻¹⁢. Compared exactly, that is not a tie at all, and half-up would send it down to 1.00.

    4. The gap becomes visible the moment the value is scaled to be compared. 1.005 Γ— 100 is 100.49999999999999, whose fractional part falls short of a half by 1.42 Γ— 10⁻¹⁴.

    5. Which is why the rounding here snaps. Anything within 8 machine steps of a half is treated as a half, and at this size that window is 1.79 Γ— 10⁻¹³, more than ten times wider than the gap. The panel answers the question you asked about the decimal rather than the one the binary asked.

    6. The tolerance is not free, and the column shows what it costs. A thousand values ending in .005, each pushed up by half a hundredth, carry the total 5.00 above the truth. Half-to-even splits the same ties and comes in at 0.07.

    7. Two of the other presets are different in kind. 2.5 and 12.5 have exact binary forms, so they are ties inside the machine as well as on paper and no tolerance is involved. β€œExactly half” is a property of the decimal you typed, and it survives into the machine only for the halves that really are halves.

    Answer

    1.01, and a spreadsheet answering 1.00 is right about the number it holds and wrong about the number you typed. The stored value is 1.07 Γ— 10⁻¹⁢ below 1.005, so an exact comparison never sees a tie, and the snap is what puts the answer back where a reader expects it. No rounding rule repairs the underlying problem. Money belongs in integer cents, or in a decimal type, where 1.005 is 1.005 and the question never comes up.

Learning path

Writing a number down

References (2)

Example problems

  • A tie - 2.5 sits exactly between 2 and 3, and the rules split: half-up says 3, half-to-even says 2. Change the value to 3.5 and they agree on 4, because 4 is the even neighbour there. Half-to-even is not favouring downward β€” it is alternating.
  • Rounded twice - 2.45 to a whole number is 2. Round it to one decimal first and it becomes 2.5, and 2.5 to a whole number is 3. Neither step broke a rule, and the answers differ.
  • The one that looks like a bug - 1.005 to two decimals ought to be 1.01. Ask JavaScript or Python and both say 1.00, because 1.005 is not stored as 1.005 β€” it is stored a hair below it, and 1.005 times 100 comes out as 100.49999999999999. This tool answers 1.01, and the only reason it can is that it looks for a tie with a tolerance instead of testing for equality.
  • A long column - 6,400 values, every one of them sitting exactly on a tie. Half-up sends every single one the same way, and the total lands 3,200 too high β€” half a unit per value, no exceptions. Half-to-even, on this column, finishes 1 out.