How to describe this bug?

[Simon Marlow]

On 11/07/2012 08:36, Christian Maeder wrote:
> 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?

Several reasons:

  - 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,
	Simon



> 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>
>>> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>