29 Sep 1998 15:48:41 -0400

Related articles |
---|

[21 earlier articles] |

Re: inlining + optimization = nuisance bugs comments@cygnus-software.com (Bruce Dawson) (1998-09-24) |

Re: inlining + optimization = nuisance bugs Martin.Ward@SMLtd.Com (1998-09-26) |

Re: inlining + optimization = nuisance bugs toon@moene.indiv.nluug.nl (Toon Moene) (1998-09-29) |

Re: inlining + optimization = nuisance bugs wclodius@aol.com (1998-09-29) |

Re: inlining + optimization = nuisance bugs ralph@inputplus.demon.co.uk (Ralph Corderoy) (1998-09-29) |

Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-29) |

Re: inlining + optimization = nuisance bugs tim@wagner.princeton.edu (1998-09-29) |

Re: inlining + optimization = nuisance bugs dmr@bell-labs.com (Dennis Ritchie) (1998-09-29) |

Re: inlining + optimization = nuisance bugs dmr@bell-labs.com (Dennis Ritchie) (1998-09-29) |

Re: inlining + optimization = nuisance bugs zalman@netcom.com (1998-10-01) |

Re: inlining + optimization = nuisance bugs wclodius@aol.com (1998-10-01) |

Re: inlining + optimization = nuisance bugs qjackson@wave.home.com (Quinn Tyler Jackson) (1998-10-04) |

Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-10-04) |

From: | tim@wagner.princeton.edu |

Newsgroups: | comp.compilers |

Date: | 29 Sep 1998 15:48:41 -0400 |

Organization: | Chemistry Department, Princeton University |

References: | 98-09-149 |

Keywords: | arithmetic |

Luddy Harrison <luddy@concmp.com> writes:

*>> In other words, reading the 754 standard, one gains the impression*

*>> that it would always be in the spirit of compliance to substitute*

*>> greater precision for lesser precision.*

*>>*

*>> Yet, when it comes to compilers, this practice is often labeled as*

*>> incorrect.*

_What Every Computer Scientist Should Know About Floating-Point

Arithmetic_, David Goldberg, in Computing Surveys (March 1991) has a

long section on all the things that go wrong if you do this. If you

do a web search, you should be able to find a reprint of that article

online; look for the section "Current IEEE 754 Implementations", page

250 in my copy.

*> I'm going to be deliberately provocative here and say: if your*

*> computation has only one correct result, then you shouldn't be using*

*> floating point!*

I'm going to be deliberately provocative here, and say that if you are

naive enough to say something like that, then you shouldn't be using

floating point!

*> One of Knuth's (very few) mistakes in the implementation of TeX was*

*> the use of floating point for "glue" computations: he thought*

*> (correctly) that the tiny differences due to different precisions*

*> wouldn't affect the placement of items on a page. But one would*

*> really like the "trip test" to have just one correct result. Hence,*

*> floating point in TeX is a bad idea.*

Doesn't follow. For example, according to IEEE 754/854, such

calculations have just one correct result, the "exactly rounded" one.

And there are provable bounds on how far that answer is from the

"correct" answer.

I happen to have a summation routine that is guaranteed to sum

thousands of terms correctly to within a few machine epsilon, and

that's crucial to the work I do. Unfortunately, i have to keep it in

a separate file, and compile it without optimization, because one

compiler I uses regularly "optimizes" it into a routine whose error

grows linearly with the number of terms. For the kinds of sums I do,

that's 4 or 5 digits less precision! Just because the compiler

writers have a poor understanding of floating point!

*> [Oh, humph. If you think that floating point operations don't have a*

*> correct answer, then you definitely shouldn't be using floating point.*

*> Unfortunately, too many compiler writers seem to share this*

*> misconception. As we've said many times before, approximate is not the*

*> same as unpredictable. -John]*

Exactly. See the above cited paper for a long, long, long discussion

of this. Including why K&R's decision to do all computations in

double precision was a bad one from the standpoint of numerical

analysis.

Tim Hollebeek

email: tim@wfn-shop.princeton.edu

URL: http://wfn-shop.princeton.edu/~tim

[I will certainly agree that many compilers do a dreadful job of

implementing floating point, and as a result numerical programmers

have to go through backflips to write robust code that will work

anyway. This also suggests that the 8087's design which does

everything to 80 bits is poorly matched to existing programming

languages. -John]

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.