# Why do some languages round to the nearest EVEN integer?

Programming languages like Scheme (R5RS) and Python (see this Question) round towards the nearest even integer when value is exactly between the surrounding integers.

What is the reasoning behind this?
Is there a mathematical idea that makes following calculations easier to reason about?

(R5RS references the IEEE floating point standard as source of this behaviour.)

• Did you read floating-point-gui.de ? – Basile Starynkevitch Sep 14 '14 at 15:52
• IEEE allows multiple rounding mode. This is one of them. Some languages even allow changing the rounding mode during execution. – Tobias Brandt Sep 14 '14 at 16:36
• You may wish to read the Tie-breaking section for rounding on Wikipedia and the association reasoning behind each one of them. – user40980 Sep 15 '14 at 3:58
• Cross-site duplicate: Mathematica.SE: Why round to even integers? – apsillers Sep 15 '14 at 14:07
• "although exact is a matter of discussion with floating point numbers" It's not a matter of discussion, it's specified very precisely. For example, the numbers that are relevant here (like 42.5) can be represented exactly, because they are binary fractions. What can't be represented exactly are fractions other than binary, including decimal fractions. – svick Sep 20 '14 at 10:58

A while ago I constructed a test program for successive rounding, because it's basically a worst-case stress test for a rounding algorithm.

For each number from 0 to 9,999 it first rounds to the nearest 10, then to the nearest 100, then to the nearest 1000. (You could also think of this as 10,000 points in [0,1) being rounded to 3 places, then to 2, then to 1.) This set of numbers has a mean value of 4999.5.

If all three roundings are done using the method "round half up", then the results are as follows (first column is the rounding result, second column is how many numbers rounded to that result — i.e. it's a histogram).

``````0     445
1000  1000
2000  1000
3000  1000
4000  1000
5000  1000
6000  1000
7000  1000
8000  1000
9000  1000
10000 555
``````

The result differs from a single "round half up" to the nearest thousand 550 times out of 10,000 and the average rounded value is 5055 (higher than the original average by 55.5).

If all three roundings are done by "round half down", then the results are:

``````0     556
1000  1000
2000  1000
3000  1000
4000  1000
5000  1000
6000  1000
7000  1000
8000  1000
9000  1000
10000 444
``````

The result differs from a single "round half down" to the nearest thousand 550 times out of 10,000 and the and the average rounded value is 4944 (too low by 55.5).

If all three roundings are done using "round half odd", the result is:

``````0     445
1000  1111
2000  889
3000  1111
4000  889
5000  1111
6000  889
7000  1111
8000  889
9000  1111
10000 444
``````

The result differs from a single "round half odd" to the nearest thousand 550 times out of 10,000 and the average rounded value is 4999.5 (correct).

Finally, if all three roundings are done using "round half even", the results are:

``````0     546
1000  909
2000  1091
3000  909
4000  1091
5000  909
6000  1091
7000  909
8000  1091
9000  909
10000 1091
``````

The result differs from a single "round half even" to the nearest thousand 450 times out of 10,000 and the average rounded value is 4999.5 (correct).

I think it's obvious that round half up and round half down bias the rounded values, so that the average of rounded values no longer has the same expectation as the average of the original values, and that "round half even" and "round half odd" remove the bias by treating 5 one way half the time and the other way the other half. Successive rounding multiplies the bias.

Round half even and round half odd introduce their own kind of bias to the distribution: a bias towards even and odd digits, respectively. In both cases, again, this bias is multiplied by successive rounding, but it's worse for round half odd. I think that the explanation in this case is simple: 5 is an odd number, so round half odd has more results ending in 5 than round half even — and therefore, more results that will have to be handled specially by the next rounding.

So anyway, of the four choices, only two are unbiased, and of the two unbiased choices, round half even gives the best-behaved distribution when subject to repeated rounding.

It's called banker's rounding. The idea is to minimize the cumulative error from many rounding operations.

Lets say you always rounded .5 down. Think of all those little interest payments, the bank pocketing half a cent each time...

Lets say you always rounded .5 up. Accounting is going to scream because you're paying out more interest than you should.

• but why even and not odd? – ratchet freak Sep 14 '14 at 16:33
• @ratchetfreak - so small numbers round to, not away from, zero. Other than that, it's arbitrary - has to be something. – Jonathan Dursi Sep 14 '14 at 19:10
• @ratchetfreak: What would happen if you start with the number 1, divide by 2, and round to odd? You get 0.5 rounded to 1. What if you divide by 2 again? You get 0.5 rounded to 1. And so on. Never becomes zero. – gnasher729 Sep 14 '14 at 23:18
• I think even numbers are also to be preferred to odd numbers because they lower the probability for the need of subsequent rounding dilemmas. Division by (exactly) two being a rather frequent operation in practice. – Marc van Leeuwen Sep 15 '14 at 3:51
• It is important in statistics too. If every fractional member of a data set is rounded up, descriptive stats such as the mean will be (slightly) higher than if it's rounded down. Kenneth Rothman's Introduction to Epidemiology specifically mentions always rounding terminal .5 (or .005, or whatever) up as gradually biasing a database towards higher numbers, but always rounding to an even or odd number does not bias the average. – Will Murphy Sep 15 '14 at 12:56