This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Porposal: Floating-Point Options


On 2005-06-15 12:53:26 +1000, Russell Shaw wrote:
> Robert Dewar wrote:
> >Russell Shaw wrote:
> >>The original bug was about testing the equality of doubles. I
> >>think that's just plain mathematically bad. Error bands should be
> >>used to test for "equality", using a band that is in accordance
> >>with the minimum precision specified in the compiler
> >>documentation.
> >
> >That's often taught, but in fact there are many IEEE algorithms
> >where it makes perfectly good sense to test for absolute equality.

Yes, and it may also make sense even if you only have a faithful
rounding (something weaker than correct rounding, as specified by
IEEE 754), for instance.

FYI, here's an example of an algorithm to determine the radix:

A = 1.0
B = 1.0
while ((A + 1.0) - A) - 1.0 == 0.0
  A = 2.0 * A
while ((A + B) - A) - B != 0.0
  B = B + 1.0

When implementing this algorithm in C, you need some casts to double
(or additional variable assignments) to discard the possible extended
precision, but with gcc, nothing would be guaranteed unfortunately
(and I'm not talking about using -ffast-math).

[...]
> But isn't equality broken if it doesn't work because of excess
> precision?

No, the bug isn't at the equality level. But if you do

  (double) x == (double) y

then the extended precision should be discarded (due to the cast),
what gcc doesn't.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]