How to describe this bug?
marlowsd at gmail.com
Wed Jul 11 10:25:39 CEST 2012
On 11/07/2012 08:36, Christian Maeder wrote:
> I think this bug is serious and should be turned into a ticket on
> 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?
- the fix hurts performance badly, because you have to store floats
into memory after every operation. (c.f. gcc's -ffloat-store option)
- the fix is complicated
- good workarounds exist (-msse2)
- it is rarely a problem
> What is the problem to disable -fexcess-precision or enable -msse2 (on
> most machines) by default?
-fexcess-precision cannot be disabled on x86 (that is the bug).
-msse2 is not supported on all processors, so we can't enable it 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 <shahn at cs.tu-berlin.de>
>>>> 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
>>> and another has been moved to memory and rounded and move back to
>>> 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
>> 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.
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users