19 Sep 1998 21:20:40 -0400

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

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.