Double -> CDouble, realToFrac doesn't work
I need to convert a Double to a CDouble to pass to a C function. In the past, when I've asked how to do this, I'm told: realToFrac. This works in most cases, but recently gave me a problem that took me *forever* to track down: Prelude Foreign.C> (0 :: CDouble) / 0 NaN Prelude Foreign.C> (0 :: Double) / 0 NaN Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble -Infinity yikes! the NaN got turned into a -Infinity!!! aside from manually checking for 'strange' Double/CDouble values and wrapping realToFrac, is there a better way? also, does this count as a bug? -- Hal Daume III | hdaume@isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume
Hal Daume III wrote:
[...] Prelude Foreign.C> (0 :: CDouble) / 0 NaN Prelude Foreign.C> (0 :: Double) / 0 NaN Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble -Infinity
yikes! the NaN got turned into a -Infinity!!!
aside from manually checking for 'strange' Double/CDouble values and wrapping realToFrac, is there a better way? also, does this count as a bug?
Hmmm, this is a little bit of a dark corner in the H98 report, but there are probably other people on this list who know better than me. :-] The problem is that 'realToFrac' is defined as 'fromRational . toRational', so the first question is: How is 'toRational' supposed to handle NaN? One thing coming to my mind is '0 :% 0', but this is normally a value which can't be constructed. So the next question is: Would this be allowed? +Infinity and -Infinity could be represented similarly then ('1 :% 0' and '(-1) :% 0'), and 'fromRational' could handle these values specially. But I can't believe that this has been discussed for the first time. SPJ? Malcolm? When you compile the stuff above with optimizations on, you get what you've expected, thanks to RULES which shortcut the route via Rational completely. Cheers, S.
participants (2)
-
Hal Daume III -
Sven Panne