Rounding a number to nearest even

hdante hdante at gmail.com
Fri Apr 11 22:44:15 CEST 2008


On Apr 11, 3:33 pm, Lie <Lie.1... at gmail.com> wrote:
>
> 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

 But then, the "Round up" table gives inconsistent results if, by the
same argument, we consider 2.0 -> 2 rounding up. (you get 12 round ups
and 8 round downs just by "rethinking" the argument). So, "rounding
up" is, at the same time, better and worse than rounding to nearest
even.

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

 The assertion is false, because there's no problem in rounding up,
truncating, etc. Just consider the amount of code snippets in this
thread. A simpler solution may solve a lot of problems.



More information about the Python-list mailing list