Does anybody know why the implementers chose to round half numbers
(i.e. n+(1/2) where n is an integer) to the EVEN integer? i.e.
(round 1.5)=2
(round 0.5)=0
There must be a good reason. I've combed the faqs and the common lisp
manual and have not found it.
I have yet to see an example where this is considered superior to
4/5'ths rounding i.e. (floor (+ x 0.5)). It would have been nicer to
have n.5 to round in the same direction each time (up) or down. But
these decisions were made long ago by bright people. They must have
had a reason. Anybody care to enligten me?
In article <··········@mule2.mindspring.com>,
Michael Tuchman <···@dur.mindspring.com> wrote:
> Does anybody know why the implementers chose to round half numbers
> (i.e. n+(1/2) where n is an integer) to the EVEN integer? [...]
> I have yet to see an example where this is considered superior to
> 4/5'ths rounding i.e. (floor (+ x 0.5)). It would have been nicer
> to have n.5 to round in the same direction each time (up) or down.
I think the rule is there so that you can round without introducing
a statistical bias. If you always round n.5 up, you will be rounding
up more often than rounding down. The bias is especially severe
when you don't have many significant digits in the first place.
Consider this example:
? ; let's start with a list of integers...
(setq data (do ((n 100 (1- n)) (l nil (cons n l))) ((minusp n) l)))
(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ...)
? ; and find the average value...
(defun avg (l) (float (/ (apply #'+ l) (length l))))
AVG
? (avg data)
50.0
? ; and the average after rounding to multiples of 10...
(avg (mapcar #'(lambda (n) (* (round n 10) 10)) data))
50.0
? ; and the average after rounding WITHOUT the even rule...
(avg (mapcar #'(lambda (n) (* (floor (+ n 5) 10) 10)) data))
50.495049504950494
-- Robert
A main point is that round-off performance depends on the "population" of
numbers to which calculations are to be applied.
In fixed-point decimal notation, suppose that the digits on either side of
the decimal point are all equally likely among (0,1,,,,9). If, furthermore,
positive and negative numbers are equally frequent, then there are exactly
199 equally-likely cases to consider:
(-_9.9_, -_9.8_,..., -_0.1_, _0.0_, _0.1_,... _9.8_, _9.9_)
where _i.j_ stands for any number with respective digits i,j immediately
before and after the decimal point. If there are only non-negative numbers,
then there are exactly 100 cases:
(_0.0_, _0.1_,... _9.8_, _9.9_)
&etc for alternative assumptions about the population.
The value of the round-off error is easily obtained for each case in the
list, giving the following table for round-off errors and their frequencies
of occurence among the 199 or 100 cases:
-------------------------------------------------------
Round-off Error Expected
-0.5 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 0.3 0.4 0.5 R-O Error
-------------------------------------------------------
(signed pop.)
"NEI" 10 20 20 20 20 19 20 20 20 20 10 0
"4/5" 0 20 20 20 20 19 20 20 20 20 20 10/199=.05+
(unsigned pop.)
"NEI" 5 10 10 10 10 10 10 10 10 10 5 0
"4/5" 0 10 10 10 10 10 10 10 10 10 10 5/100=.05
where "NEI" labels the Nearest Even Integer rounding method,
and "4/5" labels the floor(x+.5) method.
Of course the round-off errors will propagate into the result of any
calculations on the population. For example, with AVG = (x1+...+xn)/n,
Expected Error of AVG using "4/5" rounded values = (.05+...+.05)/n = .05
This would inflate proportionately to .5 if AVG were calculated on 10*x,
as in the adjacent posting using (0,1,...100) as "population"
-- (0,1,...,99) would be directly comparable to the "unsigned pop." above
(the value 100 has 0 round-off, reducing the "4/5" bias to 50.495-50=.495
instead of .5)
Note: AVG is a linear function -- non-linear ones may show greater bias.)
--
Michael Tuchman <···@dur.mindspring.com> wrote in article
<··········@mule2.mindspring.com>...
> Does anybody know why the implementers chose to round half numbers
> (i.e. n+(1/2) where n is an integer) to the EVEN integer? i.e.
> There must be a good reason. I've combed the faqs and the common lisp
> manual and have not found it.
>
> I have yet to see an example where this is considered superior to
> 4/5'ths rounding i.e. (floor (+ x 0.5)). It would have been nicer to
> have n.5 to round in the same direction each time (up) or down. But
> these decisions were made long ago by bright people. They must have
> had a reason. Anybody care to enligten me?