Re: inlining + optimization = nuisance bugs

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]


--

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