From owner-cvs-all@FreeBSD.ORG Fri Mar 7 02:52:01 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 B122F1065674 for ; Fri, 7 Mar 2008 02:52:01 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd2mo3so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 84DFA8FC19 for ; Fri, 7 Mar 2008 02:52:01 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JXC00863AMP8510@l-daemon> for cvs-all@FreeBSD.ORG; Thu, 06 Mar 2008 19:52:01 -0700 (MST) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd3mr3so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JXC002V4AMO4M60@pd3mr3so.prod.shaw.ca> for cvs-all@FreeBSD.ORG; Thu, 06 Mar 2008 19:52:01 -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 <0JXC00BJJAMMG070@l-daemon> for cvs-all@FreeBSD.ORG; Thu, 06 Mar 2008 19:52:00 -0700 (MST) Received: (qmail 2427 invoked from network); Fri, 07 Mar 2008 02:51:58 +0000 Received: from unknown (HELO hexahedron.daemonology.net) (127.0.0.1) by localhost with SMTP; Fri, 07 Mar 2008 02:51:58 +0000 Date: Thu, 06 Mar 2008 18:51:58 -0800 From: Colin Percival In-reply-to: <20080307022416.GA53988@zim.MIT.EDU> To: Colin Percival , Bruce Evans , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Message-id: <47D0ADCE.2070405@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> <47CF9586.70707@freebsd.org> <20080307085031.P10724@delplex.bde.org> <47D089A4.4060208@freebsd.org> <20080307022416.GA53988@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: Fri, 07 Mar 2008 02:52:01 -0000 David Schultz wrote: > On Thu, Mar 06, 2008, Colin Percival wrote: >> explicit or implicit final destination. When a variable with a declared format >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> is a final destination, as in format conversion to a variable, that declared >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> format of that variable governs its rounding. The format of an implicit >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> destination, or of an explicit destination without a declared format, is >> defined by language standard expression evaluation rules. > > I think you missed the point about implicit destinations. No. Another quote: 2.2.14 destination: The location for the result of an operation upon one or more operands. A destination might be either explicitly designated by the user or implicitly supplied by the system (for example, intermediate results in subexpressions or arguments for procedures). [...] Implicit destinations are things like the (x * y) in "x * y - 1.0" or in "sqrt(x * y)". > The register is an implicit destination. IEEE 754R explains this > in more detail. Really? I can't find any such statements... quite the contrary. > All that is guaranteed in this case is that the > wider register value is never substituted for z in subsequent > operations. (This is part of what gcc gets wrong.) If IEEE754R intended that "z = x + y" with x, y, and z all doubles did not guarantee reproducible results across compliant platforms, why does it say exactly the opposite? >> What standard states that those bounds are required (or can be relied upon >> when proving that code is correct)? [...] > > There's no standard requirements, but a max error < 0.50x ulps > implies correct rounding nearly all of the time, and that's what > libm attempts to provide. This is about the best you can do > without resorting to multiprecision arithmetic in the hard cases, > so it seems like a good tradeoff between accuracy and ease of > implementation. When substantially faster and slightly less > accurate MD implementations are available, that changes the > tradeoff. Sure. As I said before, more accurate transcendental functions are always nice to have, but they are not *required* by any standard. Correctly-rounded arithmetic operations *are* required. Colin Percival