Rounding a number to nearest even

[Lie]

On Apr 11, 10:19 pm, Mikael Olofsson <mik... at isy.liu.se> wrote:
> cokofree... at gmail.com commented about rounding towards even numbers
> from mid-way between integers as opposed to for instance always rounding
> up in those cases:
>
> > Strange request though, why do you need it that way, because 2.5 is
> > CLOSER to 3 than to 2...
>
> That's exactly how I was taught to do rounding in what-ever low-level
> class it was. The idea is to avoid a bias, which assumes that the
> original values are already quantized. Assume that we have values
> quantized to one decimal only, and assume that all values of this
> decimal are equally likely. Also assume that the integer part of our
> numbers are equally likely to be even or odd. Then the average rounding
> error when rounding to integers will be 0.05 if you always round up when
> the decimal is 5. If you round towards an even number instead when the
> decimal is 5, then you will round up half of those times, and round down
> the other half, and the average rounding error will be 0. That's the
> idea. Of course you could argue that it would be even more fair to make
> the choice based on the tossing of a fair coin.

That old-school rounding method you're taught is based on a wrong
assumption of the nature of number. In the past, rounding algorithm is
based on this:

Original => (RoundUp(u|d|n), RoundNearestEven(u|d|n)
...
1.0 => 1(n), 1(n)
1.1 => 1(d), 1(d)
1.2 => 1(d), 1(d)
1.3 => 1(d), 1(d)
1.4 => 1(d), 1(d)
1.5 => 2(u), 2(u)
1.6 => 2(u), 2(u)
1.7 => 2(u), 2(u)
1.8 => 2(u), 2(u)
1.9 => 2(u), 2(u)
2.0 => 2(n), 2(n)
2.1 => 2(d), 2(d)
2.2 => 2(d), 2(d)
2.3 => 2(d), 2(d)
2.4 => 2(d), 2(d)
2.5 => 3(u), 2(d)
2.6 => 3(u), 3(u)
2.7 => 3(u), 3(u)
2.8 => 3(u), 3(u)
2.9 => 3(u), 3(u)
...

In this used-to-be-thought-correct table, Round Ups algorithm have 2
Unrounded, 8 Round Down, and 10 Round Ups which seems incorrect while
Round Even have 2 Unrounded, 9 Round Down, and 9 Round Up which seems
correct. The misunderstanding comes from a view that thinks that there
is such thing as Not Rounded while in fact the only number that is Not
Rounded is 1 and 2 while 1.0 and 2.0 must still be rounded, in
practice we can just say that all number must be rounded somewhere.

Original => (RoundUp(u|d), RoundNearestEven(u|d)
...
1.0 => 1(d), 1(d)
1.1 => 1(d), 1(d)
1.2 => 1(d), 1(d)
1.3 => 1(d), 1(d)
1.4 => 1(d), 1(d)
1.5 => 2(u), 2(u)
1.6 => 2(u), 2(u)
1.7 => 2(u), 2(u)
1.8 => 2(u), 2(u)
1.9 => 2(u), 2(u)
2.0 => 2(d), 2(d)
2.1 => 2(d), 2(d)
2.2 => 2(d), 2(d)
2.3 => 2(d), 2(d)
2.4 => 2(d), 2(d)
2.5 => 3(u), 2(d)
2.6 => 3(u), 3(u)
2.7 => 3(u), 3(u)
2.8 => 3(u), 3(u)
2.9 => 3(u), 3(u)
...

In this table, we consider that a number is rounded down when the
number is equal to truncated value (the number without fractional
part), while round up is equal to truncated value + 1 or truncated
value -1 if value is negative (Actually this is not round-half-up
algorithm, it's a round-half-away-from-zero algorithm, but lets just
consider that to be the same for now). In this revised table, you get
10 round ups and 10 round down (i.e. Average Rounding Error == 0),
while by rounding to nearest even you get 9 round up and 11 round down
(i.e. Average Rounding Error != 0).

> Note that if you do not have quantized values and assuming that the
> fraction part is evenly distributed between 0 and 1, than this whole
> argument is moot. The probability of getting exactly 0.5 is zero in that
> case, just as the probability of getting any other specified number is zero.

Another mistake, in an unquantized value the probability of getting
exactly 0.5 (or any other number specified) is not 0 but an
infinitesimal (i.e. lim(x) where x -> 0 (BUT NOT ZERO))

> That said, measurements are in practice always quantized, and rounding
> towards an even number when mid-way between avoids an average error of
> half the original precision.

> As a side-note: The the smallest coin in Swedish currency SEK is 0.50,
> but prices in stores are given with two decimals, i.e. with precision
> 0.01. But what if your goods add up to 12.34? The standard in Swedish
> stores, after adding the prices of your goods, is to round the number to
> the nearest whole or half SEK, which means that decimals 25 and 75 are
> mid-way between. In those cases the rounding is usually done to the
> nearest whole SEK, which is based on precicely the above reasoning. If
> they did not do that, I could argue that they are stealing on average
> 0.005 SEK from me every time I go to the store. Well... I could live
> with that, since 0.005 SEK is a ridiculously small amount, and even if I
> make thousands of such transactions per year, it still sums up to a
> neglectable amount.

No the reason is not that, it's because 1) it is much easier to input
integral numbers to computer (calculator or cashier machine), to
input .5 to computer you have to press two more buttons or at least
one shortcut button and 2) if you have two lists, one with a bunch of .
5's and the other just a few of them you would know that it's easier
to sum the latter list with or without calculator.


> Another side-note: My 12-year old son is now being taught to always
> round up from mid-way between. Yet another example of the degradation of
> maths in schools.

A false assertion from a false understanding. The use of Round Up
algorithm is a refinement of the false understanding we used to
practice in the past.