compare on Double

[Sven Panne]

On Tuesday 20 March 2007 16:22, Ian Lynagh wrote:
> Proposal: http://hackage.haskell.org/trac/ghc/ticket/1239
>
> Consider:
>
>     let n = 0/0 :: Double in (n `compare` n, n < n, n == n, n > n)
>
> In GHC and YHC this gives
>
>     (GT,False,False,False)
>
> while in hugs it gives
>
>     (EQ,False,False,False)
>
> Neither of these is very satisfactory, as I would expect [...]

I think all 'False' are very satisfactory, at least when one is expecting IEEE 
behaviour. The only real problem is the Ordering part: The Haskell 98 report 
explicititly states that "The Ord class is used for totally ordered 
datatype". Obviously, this excludes IEEE floating point numbers, which are 
*not* totally ordered. So what can we do here?

   * Throw an exception when 'compare' sees a NaN: This gives me a rather bad 
feeling, because all other floating point operations I'm aware of in all 
current Haskell implementations do not throw any exception. Of course the 
Haskell 98 report is extremely vague about this and would allow throwing an 
exception, but a fundamental difference between (<), (>), ... and 'compare' 
would not be nice.

   * Disallow 'instance Ord Float' and 'instance Ord Double': This would 
contradict the report.

   * Let (<), (>), ... throw an exception for NaN, too: Allowed by the report, 
too, but this would surprise even more people. Furthermore, those operations 
couldn't be mapped directly to IEEE processor operations anymore.

   * Fix the Haskell report somehow: I think that in the long run this would 
be the best solution. Either Ordering would get a fourth alternative for 
uncomparable values, or some words of warning should be added to the 
description of the Ord class. What's the status of Haskell' regarding 
floating point operations? Other languages like e.g. Java are very specific 
about this topic, but this comes at a price (e.g. logical negation does not 
distribute over floating point relational operations anymore).

I propose to leave implementations as they are currently, following the TITO 
principle ("trash in, trash out"). BTW, OpenGL explicitly states that *no* 
operation leads to OpenGL interruption or termination, even if NaN, 
infinities, etc. are involved. The operations are just undefined in the 
latter cases. So we would be in good company then... :-)

Cheers,
   S.