precision/rounding bug with floating point numbers on 32-bit-platforms

[shahn]

Comparing floating point numbers (Floats or Doubles, using (==)) that are constructed by equal terms sometimes evaluates to False. A term that produces normal floating point values (as opposed to NaN or Infinity) should always be equal to itself. This bug effectively breaks referential transparency.

This bug occurs with ghc-7.4.2 when compiling with "-O2" on 32-bit linux ubuntu-11.10. (I guess, it happens on all 32-bit platforms.)

The attached file demonstrates the bug.

Simon Marlow expressed his doubts, this bug will be fixed. See also:  http://www.haskell.org/pipermail/glasgow-haskell-users/2012-July/thread.html#22565

Possible workarounds:

• compile with "-msse2" if available
• use approximate equivalence

[simonmar]

I will document this bug.

[Khudyakov]

I think it's duplicate of #5165

[marlowsd@…]

commit 43405edbe91d16b289948b9cf442e0bd1b33abdf

Author: Simon Marlow <marlowsd@gmail.com>
Date:   Fri Jul 13 10:23:12 2012 +0100

    Document bug in the x86 NCG w.r.t. -fexcess-precision (#7069)

 docs/users_guide/bugs.xml  |   30 ++++++++++++++++++++++++++++++
 docs/users_guide/using.xml |    8 ++++++++
 2 files changed, 38 insertions(+), 0 deletions(-)

[simonmar]

Documented as a known bug, thanks.

[maeder]

Is it possible to set the FLDCW "floating-point load control-word" as described in  http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html?

[simonmar]

Replying to maeder:

Is it possible to set the FLDCW "floating-point load control-word" as described in  http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html?

As it happens I considered that back in 2003(!) and wrote a comment about it:  this comment

[maeder]

Maybe it is enough that (true) floating point arithmetic yields non-deterministic results. The problem here regards equality, which need not be the same as "a - b == 0". So if we implement

a == b = show a == show b

(or more efficiently using rounding)

then this better reflects the data model, i.e. for set instances (and the expected behavior for this ticket).

Yet, almost all number laws are broken, i.e.

a == b ==> a - b == 0

But maybe this is more acceptable (with a broken FPU).

The difference between the "equal" values 0.65999289 and 0.65999289 (of the given example) happens to be 5.551115123125783e-17 (so is clearly visible as Double).

[maeder]

Independent Eq and Ord instances for Float and Double would also allow to produce run-time errors when one of the arguments is NaN.