Re: inlining + optimization = nuisance bugs

Martin.Ward@SMLtd.Com (Martin Ward)
26 Sep 1998 01:49:42 -0400

          From comp.compilers

Related articles
[16 earlier articles]
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-22)
Re: inlining + optimization = nuisance bugs zalman@netcom.com (1998-09-22)
Re: inlining + optimization = nuisance bugs chase@world.std.com (David Chase) (1998-09-22)
Re: inlining + optimization = nuisance bugs christian.bau@isltd.insignia.com (1998-09-22)
Re: inlining + optimization = nuisance bugs andrewf@slhosiery.com.au (Andrew Fry) (1998-09-24)
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: arithmetic design, was inlining + optimization = nuisance bugs christian.bau@isltd.insignia.com (1998-09-29)
[6 later articles]
| List of all articles for this month |

From: Martin.Ward@SMLtd.Com (Martin Ward)
Newsgroups: comp.compilers
Date: 26 Sep 1998 01:49:42 -0400
Organization: Compilers Central
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.
...
> [Honest, when I said wrong I meant wrong. More precision is good, but
> unpredictable precision is a disaster. Calculating error bounds is
> important in numerical analysis, but when you get down to a sequence
> of instructions, it only has one correct result. -John]


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! You should never compare floating point numbers for
equality (so John's argument that a*a - b*b might sometimes be
non-zero when a=b doesn't hold any weight: you should never compare
the result to zero anyway!)


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.


On the other hand, if you can live with a "fuzzy" result (and if you
are a numerical analyst, you _have_ to), then you should be able to
live with a nondeterministically fuzzy result.


"Floating point numbers are like heaps of sand: every time you move
one you lose a bit of sand and pick up a bit of dirt." (Not one of
mine: I can't remember who said it first).


Martin


Martin.Ward@durham.ac.uk http://www.dur.ac.uk/~dcs0mpw/ Erdos number: 4
Maintainer of the G.K.Chesterton web site: http://www.dur.ac.uk/~dcs0mpw/gkc/
Shortcuts: http://i.am/mw and http://i.am/gkc -- try them!
[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]


--


Post a followup to this message

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