compare on Double
sven.panne at aedion.de
Wed Mar 21 13:17:04 EDT 2007
On Tuesday 20 March 2007 16:22, Ian Lynagh wrote:
> Proposal: http://hackage.haskell.org/trac/ghc/ticket/1239
> let n = 0/0 :: Double in (n `compare` n, n < n, n == n, n > n)
> In GHC and YHC this gives
> while in hugs it gives
> 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... :-)
More information about the Libraries