cvs commit: src/sys/i386/include _types.h

[David Schultz]

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.