Equality == comparisons with floating point numbers
John Colvin
john.loughran.colvin at gmail.com
Sat Dec 7 02:52:07 PST 2013
On Friday, 6 December 2013 at 13:47:12 UTC, Joseph Rushton
Wakeling wrote:
> A dangerous topic for everyone :-)
>
> I've been working with some unittests involving comparing the
> output of different but theoretically equivalent versions of
> the same calculation. To my surprise, calculations which I
> assumed would produce identical output, were failing equality
> tests.
>
> It seemed unlikely this would be due to any kind of different
> rounding error, but I decided to check by writing out the whole
> floating-point numbers formatted with %.80f. This confirmed my
> suspicion that the numbers were indeed identical.
> You can read the detailed story here:
> https://github.com/D-Programming-Language/phobos/pull/1740
>
> It seems like I can probably use isIdentical for the unittests,
> but I am more concerned about the equality operator. I
> completely understand that equality comparisons between FP are
> dangerous in general as tiny rounding errors may induce a
> difference, but == in D seems to see difference in
> circumstances where (so far as I can see) it really shouldn't
> happen.
>
> Can anybody offer an explanation, a prognosis for improving
> things, and possible coping strategies in the meantime (other
> than the ones I already know, isIdentical and approxEqual)?
When you print out, you print out at type-precision. The
comparison could be happening at higher precision with trailing
precision from the last calculation.
I'm pretty sure D is free to do this, it goes with the whole
more-precision-is-better-precision philosophy.
More information about the Digitalmars-d-learn
mailing list