Hi,
I think this bug is serious and should be turned into a ticket on
http://hackage.haskell.org/trac/ghc/
Would you do so Sönke?
The abstraction of floats (Float or Double) is broken if equality
considers (random and invisible) excess bits that are not part of the
ordinary sign, exponent and fraction representation.
It should also hold: show f1 == show f2 => f1 == f2
and: read (show f) == f
(apart from NaN)
Why do you "doubt that we'll ever fix this", Simon?
What is the problem to disable -fexcess-precision or enable -msse2 (on
most machines) by default?
Cheers Christian
Am 10.07.2012 14:33, schrieb Simon Marlow:
On 10/07/2012 12:21, Aleksey Khudyakov wrote:
On Tue, Jul 10, 2012 at 3:06 PM, Sönke Hahn <sh...@cs.tu-berlin.de>
wrote:
I've attached the code. The code does not make direct use of
unsafePerformIO. It uses QuickCheck, but I don't think, this is a
QuickCheck bug. The used Eq-instance is the one for Float.
I've only managed to reproduce this bug on 32-bit-linux with ghc-7.4.2
when compiling with -O2.
It's expected behaviour with floats. Calculations in FPU are done in
maximul precision available. If one evaluation result is kept in
registers
and another has been moved to memory and rounded and move back to
registers
number will be not the same indeed.
In short. Never compare floating point number for equality unless you
really know
what are you doing.
I consider it a bug, because as the original poster pointed out it is a
violation of referential transparency. What's more, it is *not* an
inherent property of floating point arithmetic, because if the compiler
is careful to do all the operations at the correct precision then you
can get determinstic results. This is why GHC has the
-fexcess-precision flag: you have to explicitly ask to break referential
transparency.
The bug is that the x86 native code generator behaves as if
-fexcess-precision is always on. I seriously doubt that we'll ever fix
this "bug": you can get correct behaviour by enabling -msse2, or using a
64-bit machine. I don't off-hand know what the LLVM backend does here,
but I would guess that it has the same bug.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
