[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".


More information about the Haskell-Cafe mailing list