24 Jan 2002 13:55:24 -0500

Related articles |
---|

re: Compiler bugs chase@world.std.com (David Chase) (2002-01-03) |

Re: Compiler bugs christian.bau@cbau.freeserve.co.uk (Christian Bau) (2002-01-05) |

Re: Compiler bugs chase@world.std.com (David Chase) (2002-01-14) |

Bit-exact floating-point computations fare+NOSPAM@tunes.org (Francois-Rene Rideau) (2002-01-17) |

Re: Bit-exact floating-point computations christian.bau@cbau.freeserve.co.uk (Christian Bau) (2002-01-18) |

Re: Bit-exact floating-point computations fare@tunes.org (Francois-Rene Rideau) (2002-01-24) |

Re: Bit-exact floating-point computations chase@world.std.com (David Chase) (2002-01-24) |

Re: Bit-exact floating-point computations christian.bau@cbau.freeserve.co.uk (Christian Bau) (2002-01-28) |

Re: Bit-exact floating-point computations nmm1@cus.cam.ac.uk (2002-01-30) |

From: | David Chase <chase@world.std.com> |

Newsgroups: | comp.compilers |

Date: | 24 Jan 2002 13:55:24 -0500 |

Organization: | The World : www.TheWorld.com : Since 1989 |

References: | 02-01-015 02-01-029 02-01-054 02-01-066 02-01-080 |

Keywords: | arithmetic |

Posted-Date: | 24 Jan 2002 13:55:24 EST |

Christian Bau wrote:

*> But this is a totally different thing: To get bit identical results*

*> (for sine, cosine and so on) you don't need the ridiculous precision*

*> that Java prescribes. What you want is that sin (1.0e300) produces the*

*> same result on your machine as on mine. That is easily achieved by*

*> defining the actual code that the sin implementation uses, and by*

*> defining semantics of + - * / as bit exact as Java does anyway. That*

*> can still be achieved easily.*

That is exactly what Java does. The specification defines the results

as being as if from fdlibm, translated appropriately from C to Java.

You can accomplish this by translating fdlibm from C to Java (easy,

done that) or by correcting the C for the compiler bugs on your

favorite platform (easy, done that, too). This happens to provide

answers within 1 LSB, even for inputs as large as 1.0e300 (*). For

small inputs (0..PI/4) this also appears to be as fast as or faster

than hardware, especially if the inputs have their range checked (so

as to determine whether they are in the range where the hardware

actually provides an approximate answer). So, what you propose as

being different from what Java does, is exactly what Java does.

Furthermore, fdlibm is the only freely available source code that I

know of that does an adequate job of computing these transcendentals.

Replicating the behavior of the Pentium hardware on most other

hardware (i.e., most other hardware with 53-bit mantissa, smaller than

the 68-bit approximation to PI used in the hardware range reduction)

would also be about as slow as what fdlibm does for most inputs, plus

the actual algorithm used by Pentium for in-range calculation of sin

and cos is (to my knowledge) unpublished.

(*) I am running the test now, but the constructive reals run

substantially more slowly when performing 300-digit arithmetic. So

far, the error distributions resemble those seen for smaller

calculations.

David Chase

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.