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.)

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).

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:

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:

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:

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.

Filed under: softwareengineering - @ 23:13

Thẻ: numbers, numeric-precision, python-3.x, scheme

Thiết kế website giá rẻ

Danh mục

Why do some languages round to the nearest EVEN integer?