Steven G. Kargl (kar...@troutmask.apl.washington.edu)
Jun 7, 2004 1:28:05 am
David Schultz wrote:
On Fri, Jun 04, 2004, David Schultz wrote:
Sorry, I've put this off way too long. The good news is that I'm
now going to do something about it. The bad news is that I found
a significant bug in the proposed implementation. Namely, round()
and roundf() often get the wrong answer for halfway cases. In
IEEE-754 round-to-nearest mode, numbers that are halfway between
two representable numbers are supposed to be rounded to even.
It seems I've paged out more material from my brain than I thought
since I last looked at this. POSIX defines round() to
specifically *not* use the IEEE-754 round-to-nearest behavior.
Your implementation is absolutely correct, Steve, and it even gets
the exception flags right. (I tested all positive inputs to
roundf(), probed inputs to round() uniformly at random for a few
minutes, and checked important special cases.) I'll go ahead and
commit it with minor style and doc fixes.
I would have to go back and review the PR for all the discussion,
but I thought bde had proposed using rint(3) with an appropriate
rounding mode. Anyway, whatever you decide to do is fine with
BTW, thanks for the work on fenv. Sorry, I couldn't provide a review.
I did look at your patch, but it was way over my head.