Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#7069 closed bug (wontfix)

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

Reported by: shahn Owned by: simonmar
Priority: normal Milestone: 7.6.1
Component: Compiler Version: 7.4.2
Keywords: Float Double 32 precision rounding Cc: alexey.skladnoy@…
Operating System: Unknown/Multiple Architecture: x86
Type of failure: Incorrect result at runtime Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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

Attachments (1)

test.hs (135 bytes) - added by shahn 7 years ago.

Download all attachments as: .zip

Change History (9)

Changed 7 years ago by shahn

Attachment: test.hs added

comment:1 Changed 7 years ago by simonmar

difficulty: Unknown
Milestone: 7.6.1
Owner: set to simonmar

I will document this bug.

comment:2 Changed 7 years ago by Khudyakov

Cc: alexey.skladnoy@… added

I think it's duplicate of #5165

comment:3 Changed 7 years ago by 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(-)

comment:4 Changed 7 years ago by simonmar

Resolution: wontfix
Status: newclosed

Documented as a known bug, thanks.

comment:5 Changed 7 years ago by 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?

comment:6 in reply to:  5 Changed 7 years ago by 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

comment:7 Changed 7 years ago by 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).

comment:8 Changed 7 years ago by 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.

Note: See TracTickets for help on using tickets.