atom feed15 messages in org.freebsd.freebsd-standardsstandards/59797: Implement C99's roun...
FromSent OnAttachments
Steven G. KarglDec 9, 2003 8:43 pm 
Steven G. KarglDec 9, 2003 8:50 pm 
Steven G. KarglDec 10, 2003 9:12 am 
Steven G. KarglDec 10, 2003 9:20 am 
David SchultzJun 4, 2004 7:53 pm 
David SchultzJun 4, 2004 8:00 pm 
David SchultzJun 5, 2004 3:49 pm 
David SchultzJun 5, 2004 3:50 pm 
Steven G. KarglJun 7, 2004 1:28 am 
Steven G. KarglJun 7, 2004 1:30 am 
Steven G. KarglJun 7, 2004 1:33 am 
Steven G. KarglJun 7, 2004 1:39 am 
David SchultzJun 7, 2004 8:11 am 
David SchultzJun 7, 2004 10:10 pm 
David SchultzJun 7, 2004 10:20 pm 
Subject:standards/59797: Implement C99's round[f]() math fucntions
From:Steven G. Kargl (kar@troutmask.apl.washington.edu)
Date:Jun 7, 2004 1:28:05 am
List:org.freebsd.freebsd-standards

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

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.