[Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers

[Roman Leshchinskiy]

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