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