Related articles |
---|
[9 earlier articles] |
Re: inlining + optimization = nuisance bugs jfc@mit.edu (1998-08-19) |
Re: inlining + optimization = nuisance bugs joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (1998-08-19) |
Re: inlining + optimization = nuisance bugs roy@prism.gatech.edu (1998-08-20) |
Re: inlining + optimization = nuisance bugs awf@robots.ox.ac.uk (Andrew Fitzgibbon) (1998-08-20) |
Re: inlining + optimization = nuisance bugs bear@sonic.net (Ray Dillinger) (1998-08-22) |
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-18) |
Re: inlining + optimization = nuisance bugs cfc@world.std.com (Chris F Clark) (1998-09-19) |
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) |
[12 later articles] |
From: | Chris F Clark <cfc@world.std.com> |
Newsgroups: | comp.compilers |
Date: | 19 Sep 1998 21:20:40 -0400 |
Organization: | The World Public Access UNIX, Brookline, MA |
References: | 98-09-071 |
Keywords: | arithmetic |
> I don't find any language in the document that expresses concern for
> the use of too *much* precision. Indeed, to the extent that floating
> point numbers are intended to mimic the reals, there can be no such
> thing as too much precision.
However, you can have "too much" precision if you can't have it
universally. Take the following fragment of a basic derivative:
100 input a, b
110 let x = a*a - b*b
120 print x
130 end
Implement it on a machine with one register (the accumulator) which
has more bits than the memory. Now, give the machine the same value
for a and b, where a*a fits in the accumulator but gets round-off
errors when stored to memory. If your implementation keeps either a*a
or b*b in a register before performing the subtraction (and does not
store both values into memory), then it will get the wrong answer (it
will not get 0, which is the right answer according to both real
arithmetic and its computer approximation). It will get the wrong
answer because of the extra precision on *one* side of the expression
and not on both. Thus, it is an incorrect optimization to remove
either of the stores of the intermediate results a*a or b*b unless you
can remove both. If you have more than one register, you simply need
to invent a more complicated expression with the same properties so
that you still have to spill some portion of the calculation and that
impoverished portion requires you to spill all the calculation to get
the correct answer.
This, I know from having once implemented the above optimization in a
FORTRAN compiler and then seeing it break my users' programs. FORTRAN
users are very unforgiving of compilers that give the wrong numerical
results, although they are far more gracious to those compilers'
foolish implementors (at least face-to-face).
Hope this helps,
-Chris
*****************************************************************************
Chris Clark Internet : cfc@world.std.com
Compiler Resources, Inc. CompuServe : 74252,1375
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
------------------------------------------------------------------------------
Web Site in Progress: Web Site : http://world.std.com/~compres
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.