From owner-cvs-all@FreeBSD.ORG Thu Mar 6 06:27:21 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 530581065674; Thu, 6 Mar 2008 06:27:21 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id B534E8FC14; Thu, 6 Mar 2008 06:27:20 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m266SY7h048665; Thu, 6 Mar 2008 01:28:34 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m266SYvE048664; Thu, 6 Mar 2008 01:28:34 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 6 Mar 2008 01:28:34 -0500 From: David Schultz To: Colin Percival Message-ID: <20080306062834.GA48339@zim.MIT.EDU> Mail-Followup-To: Colin Percival , Bruce Evans , Bruce Evans , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200803051121.m25BLE03035426@repoman.freebsd.org> <47CE8396.6020803@freebsd.org> <20080306095645.V7605@delplex.bde.org> <47CF5AE8.2090101@freebsd.org> <20080306033807.GB47280@zim.MIT.EDU> <47CF7EA6.90802@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CF7EA6.90802@freebsd.org> Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, Bruce Evans , Bruce Evans , cvs-all@FreeBSD.ORG 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:27:21 -0000 On Wed, Mar 05, 2008, Colin Percival wrote: > David Schultz wrote: > > If gcc actually implemented IEEE 754R / C99 / LIA1 correctly, then > > when compiling something like 'double x = y' would require it to > > store the value to memory and then reload it to force it to 53-bit > > precision. > > Even this wouldn't work, since it would result in double rounding. Nevertheless, this is all that is guaranteed because it is often impractical to do better, and because these semantics are often sufficient. The usual formulas for splitting a number into hi + lo components work, for example. Furthermore, implementations that use extra guard bits in their FP registers can avoid the double rounding. > > The whole point of double_t is to allow the programmer > > to ask for a variable that is "at least double precision", so that > > the compiler isn't forced to clip everything to double precision > > if it's inefficient to do so. > > Right -- and that's why numerical analysts should use double (after > proving that their code will produce the correct results using > double-precision arithmetic) while people who don't understand > floating-point math should always use double_t. Not really. There are times when it matters and times when it doesn't. If you're evaluating a Chebyshev polynomial via Horner's formula, for example, imprecisions in rounding can generally be ignored until the last one or two multiplications. Similarly, if you're doing Newton iteration, only roundoff in the last iteration matters. At other times it really does matter, and numerical analysts know how to tell the difference.