I recently learned that Python's round() uses bankers' rounding: an exact halfway value rounds to whichever adjacent integer is even, so round(2.5) gives 2 while round(3.5) gives 4. The usual explanation is that always rounding .5 upward introduces a small upward bias in large datasets. But I'm confused about how to count the cases. Values ending in .1 through .4 round down, .6 through .9 round up, and .0 stays unchanged. Doesn't that mean there are five cases that go down or stay put and only four that go up? Also, why does round(2.500000000000001) return 3 while round(2.5000000000000001) returns 2? I assume the latter is because binary floating-point cannot represent that decimal distinction exactly.
3 Answers
For financial calculations, storing amounts as integer minor units can help, but it does not remove every rounding decision. Dividing, calculating interest, converting currencies, or later rounding cents to whole dollars can still create halfway cases. Use decimal arithmetic with a documented rounding mode when decimal exactness and repeatable results matter; different languages and systems do not all use bankers’ rounding by default.
The bias explanation assumes the halfway cases are reasonably distributed between even and odd neighbors. If every value happens to land on ties with the same parity, bankers’ rounding will not magically eliminate all error; it is a rule designed to avoid systematic bias in typical large, varied datasets. If your application has a specific business rule, use that rule explicitly rather than assuming round() matches schoolbook rounding.
The .0 case is not a rounding-down case—it requires no rounding at all. For values rounded to the nearest integer, .1 through .4 produce a negative rounding error, .6 through .9 produce a positive error, and .0 produces zero error. The exact .5 values are the only ambiguous cases. Rounding half to even makes some ties go down and others go up, so the tie-related errors can balance instead of always pushing the result upward. The same idea works when rounding to tens, cents, or any other decimal place.
That is also why two systems can disagree by a cent even when they receive the same input. One may use ties-to-even while another uses half-up, so the rounding policy needs to be part of the specification.