Date: Thu, 6 Mar 2008 01:28:34 -0500 From: David Schultz <das@FreeBSD.ORG> To: Colin Percival <cperciva@FreeBSD.ORG> Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, Bruce Evans <bde@FreeBSD.ORG>, Bruce Evans <brde@optusnet.com.au>, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/include _types.h Message-ID: <20080306062834.GA48339@zim.MIT.EDU> In-Reply-To: <47CF7EA6.90802@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080306062834.GA48339>