18 Sep 1998 23:09:03 -0400

Related articles |
---|

[8 earlier articles] |

Re: inlining + optimization = nuisance bugs lindahl@cs.virginia.edu (1998-08-19) |

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) |

[13 later articles] |

From: | Luddy Harrison <luddy@concmp.com> |

Newsgroups: | comp.compilers |

Date: | 18 Sep 1998 23:09:03 -0400 |

Organization: | Compilers Central |

Keywords: | arithmetic, errors, comment |

"Joseph D. Darcy" <darcy@usul.CS.Berkeley.EDU> writes:

*>>To trust or not to trust?*

*>*

*>>Quinn Tyler Jackson*

*>*

*>>[It's pretty cheezy, but I have to admit that precision problems like this*

*>>are a chronic problem in floating point code. -John]*

*>*

*>These kinds of unwanted extra-precision bugs are not new; the 680x0*

*>based Sun III compilers could introduce the same sort of surprises*

*>(these surprises also appeared even earlier on the GE635). In an*

*>effort to speed up Java's floating point the x86, Sun is proposing to*

*>allow these precision anomalies into Java*

*>*

*>-Joe Darcy*

*>darcy@cs.berkeley.edu*

*>[I've never understood why people are so eager to have fast wrong*

*>answers. -John]*

It is interesting to read the rationale narrative from the IEEE 754

floating point spec in light of this discussion. Concerning extended

precision temporaries (quoting from Draft 8.0 of IEEE 754, published

in Computer, March 1981), the authors write

The proposal also recommends the minimum requirements for

extended-precision temporaries (quantities whose range and

precision are greater than a basic format but do not require twice

as many bits for representation). With their greater precision,

extended-precision temporaries lessen the chance of a final result

that has been contaminated by excessive roundoff error; with their

greater range, they also lessen the chance of an intermediate

overflow aborting a computation whose result would have been

representable in a basic format.

Their chief concerns are (1) excessive roundoff (2) intermediate

overflow. This concern is reflected throughout the document.

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.

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. For example, the moderator's comment was

[I've never understood why people are so eager to have fast wrong

answers. -John]

whereas it would have been more to the point to say

[I've never understood why people are so eager to have fast MORE PRECISE

answers.]

because the 'wrong' answer in question arose from use of an

extended-precision temporary.

Perhaps the bit-for-bit notion of correctness that (we) compiler

writers use for validating the compilation of integer computations is

simply inappropriate for floating point computations? Would it not

make more sense to measure deviation from the result that would be

obtained if the program were executed in infinite precision, or the

result that would be obtained at a higher finite precision? While

this is harder than comparing bits, it must surely be similar to what

one goes through when calculating error bounds in a scientific

program.

-Luddy Harrison

_______________________________________________________________

Luddy Harrison Connected Components Corporation

[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]

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.