Peter Gavin <pgavin <at> gmail.com> writes:
> The reason for doing it this way is that e.g. 2.5 is
> exactly between 2 and 3, and rounding *up* every time
> would cause an uneven bias toward 3. To counteract that
> effect, rounding to the nearest even integer is used,
> which causes the half of the x.5 values to round up, and
> the other half to round down.
Everyone keeps providing this rationale, but of course if
you want "half the values to round up and the other half
down" it does just as well to round positive values up and
negative values down.
I think given that the Haskell 98 Report is pretty explicit
about the behavior of round, we're stuck with it, but I
don't like it. It's yet another tiny impediment to Haskell
newbies, as demonstrated by the original post. (I'm not at
all opposed to having a round-to-even function; it should
just be called roundHalfEven to make it clear what it
does. If it were up to me, I would probably elide the name
"round" altogether in favor of roundHalfEven.)
I have written floating point code that depends on
consistent rounding in the past. Being able to depend on
round (1 + x) = 1 + round x
is sometimes useful, but not possible for round-to-even.
Also note that for a common case, rounding numbers in the
range -x..x, there's still a strange slight bias toward the
center, since round-to-even rounds both 0.5 and -0.5 to 0.
BTW, in case anyone is unclear, IEEE 854 supports a large
variety of required and optional rounding modes; it takes no
strong position on a "correct" rounding strategy. In
particular, round-up ("round-half-up") and round-to-even
("round-half-even") are both required. However, there is an
IEEE 854 subset, ANSI X3.274, that does make rounding modes
other than round-up optional, presumably in conformance with
common PL practice. This might make an implementation of the
Report's round function on some FPU I've never heard of
slightly more expensive.
Bart Massey
bart <at> cs.pdx.edu
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
