Re: inlining + optimization = nuisance bugs

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

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