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.