1 Nov 1998 11:41:27 -0500

Related articles |
---|

[3 earlier articles] |

Re: floating point comments@cygnus-software.com (Bruce Dawson) (1998-10-07) |

Re: floating point will@ccs.neu.edu (William D Clinger) (1998-10-10) |

Re: floating point dmcq@fano.demon.co.uk (David McQuillan) (1998-10-13) |

Re: floating point darcy@CS.Berkeley.EDU (Joseph D. Darcy) (1998-10-19) |

Re: floating point darcy@usul.CS.Berkeley.EDU (1998-10-24) |

Re: floating point comments@cygnus-software.com (Bruce Dawson) (1998-11-01) |

Re: floating point comments@cygnus-software.com (Bruce Dawson) (1998-11-01) |

Re: floating point darcy@usul.CS.Berkeley.EDU (1998-11-06) |

Re: floating point darcy@CS.Berkeley.EDU (Joseph D. Darcy) (1998-11-06) |

Re: floating point comments@cygnus-software.com (Bruce Dawson) (1998-11-07) |

Re: floating point eggert@twinsun.com (1998-11-19) |

Re: floating point dmcq@fano.demon.co.uk (David McQuillan) (1998-11-21) |

Re: floating point darcy@CS.Berkeley.EDU (Joseph D. Darcy) (1998-12-01) |

[1 later articles] |

From: | Bruce Dawson <comments@cygnus-software.com> |

Newsgroups: | comp.compilers |

Date: | 1 Nov 1998 11:41:27 -0500 |

Organization: | Cygnus Software |

References: | 98-09-164 98-10-018 98-10-040 98-10-120 |

Keywords: | arithmetic |

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

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.