Re: Rounding a number to nearest even

On Apr 11, 10:19 pm, Mikael Olofsson <mik...@xxxxxxxxxx> wrote:
cokofree...@xxxxxxxxx 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.
.