Date: Fri, 4 Jun 2004 19:53:59 -0700 From: David Schultz <das@FreeBSD.ORG> To: "Steven G. Kargl" <kargl@troutmask.apl.washington.edu> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: standards/59797: Implement C99's round[f]() math fucntions Message-ID: <20040605025359.GA3084@VARK.homeunix.com> In-Reply-To: <200312101711.hBAHBoEL007529@troutmask.apl.washington.edu> References: <200311291810.hATIAIWu084953@freefall.freebsd.org> <200312101711.hBAHBoEL007529@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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. For instance, 0.5 becomes 0, and 1.5 becomes 2. I don't see an easy way to make this work in the present implementation without fiddling with the underlying bits. Perhaps we need to implement it more similarly to fdlibm's rint(). BTW, benchmarking shows that using the sample implementation that appears in the C99 standard results in a slowdown of two orders of magnitude over your round() implementation and four orders of magnitude over the x87 frndint instruction. Just setting the rounding mode and calling rint() also results in a significant slowdown. Thus, we definitely want something that's in the spirit of what you wrote, but perhaps one that operates on the bits directly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040605025359.GA3084>