According to the Mathematica help:
Round rounds numbers of the form x.5 toward the nearest even integer.
For example:
Round[{0.5, 1.5, 2.5, 3.5, 4.5}]
gives
{0, 2, 2, 4, 4}
What's the rationale behind this? Why not the usual x.5 always rounds up?
It is called bankers' rounding. The rationale is that the rounding behaves "nicely" even if you have negative numbers, i.e. rounding commutes with negation, which is nice.
Direction $\rightarrow$ {"HalfDown","HalfUp","HalfEven","HalfOdd","Stochastic"} etc.
$\endgroup$
I think the reason is to prevent biasing numbers on average upward or downward.
For example if you have a list of numbers that include a lot of x.5 and you were to round all these upward, the average magnitude of the list would also shift upward. Likewise if you round downward, downward.
By rounding to the nearest even number these would balance out, given enough samples.
SetAttributes[RoundUp, Listable]
RoundUp[a_] := If[FractionalPart[a] >= 1/2, Ceiling[a], Floor[a]]
d = Table[i, {i, 0, 100, 1/10}];
Mean[Round[d]] // N
50.
Mean[RoundUp[d]] // N
50.05
Mean[d]
50
According to Wikipedia this is also known as:
unbiased rounding, convergent rounding, statistician's rounding, Dutch rounding, Gaussian rounding, odd-even rounding3 or bankers' rounding, and is widely used in bookkeeping.
Searching for some of those terms returns many good results including:
It does not suffer from negative or positive bias as much as the round half away from zero method over most reasonable distributions. ... But the question was why [] use Banker's actual rounding as default - and the answer is that Microsoft has followed the IEEE 754 standard.
Where statistics matter, and where numbers that END with the 5 are common, the method you referred to is preferred, because it avoids a bias toward rounding up. On the other hand, there may be some situations where a bias toward numbers that end in an even digit might be bad. Each method has its place.
Ideally when you are taking an average you want to take an average of the raw data with as much precision as you can get. But in the real world we often have to take averages of data which has lost some precision. In such a situation the Banker's Rounding algorithm produces better results because it does not bias half-quantities consistently down or consistently up. It assumes that on average, an equal number of half-quantities will be rounded up as down, and the errors will cancel out.
Given a number exactly halfway between two values, round to the even value (zero is considered even here). ... For random data this is very convenient. Bankers like it because money deposited and withdrawn is random. (There are trends, mind you, but you cannot predict exactly how much will be deposited and withdrawn.) The important point is that the bankers rounding is still biased if the data is biased. It is only unbiased with random data.
One consequence of this result is that a midpoint is sometimes rounded up and sometimes down, and therefore, over the course of a long series of computations and approximations, rounding error is less likely to accumulate to a significant degree in one particular direction than it would be if the the choice were made more consistently. The cost of this feature is a more complicated definition, requiring a more expensive implementation.
Floor[a + 1/2] is the traditional way to round positive numbers in C++ (which has no built in round function).
$\endgroup$
The answer is very nicely illustrated in following link at the topics "Round-Half-Even (Banker's Rounding)" and "Round-Half-Odd":
Clive (Max) Maxfield and Alvin Brown,
Rounding Algorithms 101
http://www.clivemaxfield.com/diycalculator/popup-m-round.shtml#A5
Round to even rounds to a value with less expected followup error in further rounding operations.
It makes a weakened form of associativity hold: ((a+b)-b)+b = a+b . Basically, once you have gotten the unavoidable rounding of a+b over with, no further rounding error will occur from repeatedly subtracting and adding b.
These kind of guarantees reduce the expected maximum error of cumulative operations.
