Re: floating point

Bruce Dawson said:
> > It can introduce double rounding, and it doesn't clamp the
> > exponent. The exponent clamping can be forced by writing to memory,
> > but the double rounding is inevitable (but rare?)


Joseph D. Darcy wrote:
> The double rounding can only occur for subnormal values, which are
> very rare in practice. In the context of Java, while x86
> implementations may exhibit double rounding on underflow, this is a
> trivial exact reproducibility issue compared to faulty decimal <-->
> binary conversion (as found in Sun's JDK 1.0) and non-conformant
> transcendental functions (present in at least early iterations of JDK
> 1.1.x). As discussed by Doug Priest, such double rounding on
> underflow "is highly unlikely to affect any practical program
> adversely" [Pri].


Just to clarify: Doug Priest's quote was talking about double rounding
caused by writing doubles to memory and having the exponent range
reduced by this process. I was intending to refer to the double
rounding that happens in the x86 when the rounding mode is set to
double and the results are first rounded to 64-bit precision, and then
to 53 bit precision - even before being written to memory. On this
topic Doug Priest says:


"the procedure described in Theorem 6 for splitting a floating-point
number into high and low parts doesn't work correctly in
double-rounding arithmetic"


and:


"portable algorithms for adding multiple precision numbers represented
as arrays of double precision numbers can fail in double-rounding
arithmetic"


These quotes are from: http://www.validgh.com/goldberg/addendum.html


To demonstrate how this double rounding error can happen, in common
usage, without underflow being required, look at this decimal
example. Assume that doubles are two decimal digits, and extended is
three decimal digits.


8.8e2 (880) + 5.1e1(51) = 8.851e2(885.1). Rounding this to extended
precision gives us 8.85e2 (885). Similarly:
8.8e2 (880) + 4.9e1(49) = 8849e2(884.9). Rounding this to extended
precision also gives us 8.85e2 (885).


Rounding this result to double precision will give us either 8.8e2 or
8.9e2 - but the same result for both calculations. Since the correct
answer is 8.9e2 for the first calculation, and 8.8e2 for the second,
double rounding has struck - one of the answers will be wrong.


Hardly a rigorous proof, but as support for Doug Priest's article I'm
happy with it.


How frequently does this happen? If two doubles are sufficiently
misaligned (the exponents must differ by at least twelve) then it will
happen during addition/subtraction one time in 4096, so in the
addition/subtraction case it hinges on how frequently your exponents
differ by at least twelve but no more than 53.


Calculating the frequency for multiplication and division is left as
an exercise for, well, you know who.
--
Bruce Dawson, Cygnus Software Author of Fractal eXtreme for Win32
Get your 15 day trial copy of FX at: http://www.cygnus-software.com/
Write me at: comments@cygnus-software.com

Return to the comp.compilers page.
Search the comp.compilers archives again.