[Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point
Numbers
Roman Leshchinskiy
rl at cse.unsw.edu.au
Sat Apr 24 06:12:42 EDT 2010
On 24/04/2010, at 19:56, Barak A. Pearlmutter wrote:
>> And yet a lot of generic code is written in terms of compare.
>
> That's can be an advantage, because often that code *should* blow up
> when it gets a NaN. E.g., sorting a list of Floats which includes a
> NaN.
However, often you will know that the list doesn't contain NaNs and will still have to pay a performance penalty. It's a question of what the right default is - safety or performance. In the case of floating point numbers, I'm leaning towards performance.
That said, I would be very much in favour of providing a SafeFloat or whatever type with much safer semantics than IEEE floats and trying to get people to use that type by default unless they really need the performance.
>> Even deriving(Ord) only produces compare and relies on standard
>> definitions for other methods.
>
> I don't think that's actually a problem. Surely the IEEE Floating
> Point types would give their own definitions of not just compare but
> also <, <=, etc, overriding the problematic deriving(Ord) definitions
> of comparison in terms of compare and vice-versa.
I was thinking of this:
data T = T Double deriving ( Eq, Ord )
Unless I'm mistaken, at the moment GHC basically produces
instance Ord T where
compare (T x) (T y) = compare x y
t < u = compare t u == LT
...
That is, all comparisons on T would be paying the "NaN performance tax".
Roman
More information about the Haskell-Cafe
mailing list