From owner-freebsd-standards@FreeBSD.ORG Fri Jun 4 19:54:12 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 9073816A4CE; Fri, 4 Jun 2004 19:54:12 -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 3C07843D31; Fri, 4 Jun 2004 19:54:12 -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 i552rx92004039; Fri, 4 Jun 2004 19:53:59 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i552rx2x004038; Fri, 4 Jun 2004 19:53:59 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 4 Jun 2004 19:53:59 -0700 From: David Schultz To: "Steven G. Kargl" Message-ID: <20040605025359.GA3084@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312101711.hBAHBoEL007529@troutmask.apl.washington.edu> cc: FreeBSD-gnats-submit@FreeBSD.ORG cc: freebsd-standards@FreeBSD.ORG 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 02:54:12 -0000 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.