From owner-freebsd-standards@FreeBSD.ORG Sat Jun 5 15:49:52 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3B2F16A4CE; Sat, 5 Jun 2004 15:49:52 -0700 (PDT) Received: from VARK.homeunix.com (ar59.lsanca2-4.27.98.47.lsanca2.dsl-verizon.net [4.27.98.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82F7F43D2F; Sat, 5 Jun 2004 15:49:52 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i55MnGsK003352; Sat, 5 Jun 2004 15:49:16 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i55MnGNl003351; Sat, 5 Jun 2004 15:49:16 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 5 Jun 2004 15:49:16 -0700 From: David Schultz To: "Steven G. Kargl" , FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Message-ID: <20040605224915.GA3306@VARK.homeunix.com> Mail-Followup-To: "Steven G. Kargl" , FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG References: <200311291810.hATIAIWu084953@freefall.freebsd.org> <200312101711.hBAHBoEL007529@troutmask.apl.washington.edu> <20040605025359.GA3084@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040605025359.GA3084@VARK.homeunix.com> Subject: Re: standards/59797: Implement C99's round[f]() math fucntions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 22:49:52 -0000 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.