How to describe this bug?
alexey.skladnoy at gmail.com
Wed Jul 11 20:15:14 CEST 2012
On 11.07.2012 20:05, Tyson Whitehead wrote:
> On July 11, 2012 04:51:50 Christian Maeder wrote:
>> Is it not enough to store floats into memory just before equality tests
>> (or add rounding in the instance definitions of Float and Double in Eq
>> and Ord)?
> You have to be 100% consistent in how you do every operations in all cases
> otherwise different levels of rounding errors will creep into the results.
> It isn't too hard to imagine a floating point expression getting inlined
> somewhere, and the compiler generating code to evalulate it all in registers.
> Intermediate operations will then be done to 80 bit precision.
> Elsewhere, it doesn't get inlined and the compiler generates code to store
> intermediate results in memory. Intermediate operations will then be done to
> 32 bit precision. Different results will occur on the rounding boundaires.
> Always storing and reloading after every operations will give you consistent
> results. I guess the other option is to disable inlining etc. or somehow
> ensure they are applied consistently in all use cases of an expression.
There are more possibilities. With optimizations turned on compiler may
be able to squeeze everything into registers and do store/load
operations otherwise. However I don't consider it a problem. If your
result depends on rounding you are in deep trouble and it's quite likely
result is garbage.
Equality is a bit more complicated. It's rarely meaningful and if you do
need exact equality you'd better to ensure that number is stored because
exact behaviour depends on hardware, compiler and compiler flags.
More information about the Glasgow-haskell-users