From owner-cvs-all@FreeBSD.ORG Thu Mar 6 06:56:11 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D208106566B for ; Thu, 6 Mar 2008 06:56:11 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mo1so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 13C3F8FC1A for ; Thu, 6 Mar 2008 06:56:10 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mr6so.prod.shaw.ca (pd3mr6so-qfe3.prod.shaw.ca [10.0.141.21]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JXA00D7YR9MP640@l-daemon> for cvs-all@FreeBSD.ORG; Wed, 05 Mar 2008 23:56:10 -0700 (MST) Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7]) by pd3mr6so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JXA00013R9MAK60@pd3mr6so.prod.shaw.ca> for cvs-all@FreeBSD.ORG; Wed, 05 Mar 2008 23:56:11 -0700 (MST) Received: from hexahedron.daemonology.net ([24.80.10.198]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JXA00HVDR9KVC00@l-daemon> for cvs-all@FreeBSD.ORG; Wed, 05 Mar 2008 23:56:09 -0700 (MST) Received: (qmail 2310 invoked from network); Thu, 06 Mar 2008 06:56:08 +0000 Received: from unknown (HELO hexahedron.daemonology.net) (127.0.0.1) by localhost with SMTP; Thu, 06 Mar 2008 06:56:08 +0000 Date: Wed, 05 Mar 2008 22:56:06 -0800 From: Colin Percival In-reply-to: <20080306063452.GB48339@zim.MIT.EDU> To: Colin Percival , Peter Jeremy , Bruce Evans , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Message-id: <47CF9586.70707@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.95.5 References: <200803051121.m25BLE03035426@repoman.freebsd.org> <20080305182531.GS68971@server.vk2pj.dyndns.org> <20080306021222.GA46783@zim.MIT.EDU> <47CF5D19.3090100@freebsd.org> <20080306033246.GA47280@zim.MIT.EDU> <47CF7EBF.6000009@freebsd.org> <20080306063452.GB48339@zim.MIT.EDU> User-Agent: Thunderbird 2.0.0.9 (X11/20071117) Cc: Subject: Re: cvs commit: src/sys/i386/include _types.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 06:56:11 -0000 David Schultz wrote: > On Wed, Mar 05, 2008, Colin Percival wrote: >> Setting the i387 FPU to 53-bit precision gives standards-compliant >> behaviour whether people are using "double" or "long double". > > Not quite. How is it not standards-compliant? >> Yes and no. Double rounding isn't allowed; > > Yes, it is. No, it isn't. The following code double x, y, z; x = 1.0; y = 0x1.0p-53 + 0x1.0p-75; z = x + y; z = z - 1.0; if (z == 0.0) printf("BUGGY MATH\n"); else printf("IEEE754-COMPLIANT MATH\n"); should never output "BUGGY MATH", since x + y should round up to 1 + 2^(-52); but if you set the i387 to use extended precision, it gets the wrong answer. >>> The downside is that this breaks long doubles. >> Except that it doesn't. Using 53-bit precision for long doubles is >> a perfectly valid and standards-compliant option. > > It's impossible to implement efficient library functions that > produce correct long double results You could have stopped this sentence here -- for all practical purposes, correctly rounded trigonometric functions are not feasible. > when the FPU is set to 64-bit > mode and avoid double rounding and related problems when the FPU > is set to 53-bit mode. Fortunately, library functions aren't required to have any particular error bounds. It's always nice if they are correct to within 0.6ulp instead of 0.8ulp or suchlike -- but nobody should be proving code correctness based on assumed properties of library transcendental functions. People should, and do, prove code correct based on the assumption that double precision arithmetic behaves like double precision arithmetic, however (myself included). Colin Percival