24 Jan 2002 13:44:53 -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: | Francois-Rene Rideau <fare@tunes.org> |

Newsgroups: | comp.compilers |

Date: | 24 Jan 2002 13:44:53 -0500 |

Organization: | TUNES Project |

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

Keywords: | arithmetic |

Posted-Date: | 24 Jan 2002 13:44:53 EST |

Christian Bau <christian.bau@cbau.freeserve.co.uk> writes:

*>> "Write Once, Run Anywhere"?*

*>> Without bit-exact correctness, it's but a shameful lie.*

*>*

*> 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.*

Java does the right thing here: because the only future-proof way of

defining sin(1.0e300) is the bit-exact correct result. Standardizing

a kluge is the best way to build heaps of rubbish in the future so as

to be backward compatible with ancient Java applications when all modern

processors of the day (say in 2010) compute sin(1.0e300) without problem.

An acceptable compromise would be do define a large interval inside which

bit-exact correctness is guaranteed, and outside of which warranties are

less stringent.

Allowing spurious discrepancy for the sake of speed is just Wrong(TM).

Standardizing on wrong answers is Evil(TM).

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.