Double > CDouble, realToFrac doesn't work
Simon PeytonJones
simonpj at microsoft.com
Mon Aug 9 07:51:20 EDT 2004
 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?
I don't recall a discussion about this, and a quick search in my mail
archive didn't turn up anything except the enclosed from George Russell.
I'm pretty ignorant about the dark corners of numerics, but it does seem
bad that passing through Rational loses information. Perhaps the Report
should specify normalised representations for +Inf, Inf and NaN as
Rationals (1:%0, 1:%0, and 0:%0 seem like plausible candidates).
If someone wants to try this out, and send us a patch for the Rational
library, we could incorporate it. And so far as the report goes,
perhaps the Errata could contain a note identifying the issue, and
suggesting a solution. It's a bit late to *specify* a solution unless
we are really sure about it.
Simon
Original Message
From: George Russell [mailto:ger at informatik.unibremen.de]
Sent: 25 February 2000 10:19
To: glasgowhaskellusers at haskell.org
Subject: Floatingpoint nitpicking: floor(Inf) and floor(NaN)
floor(Inf) and floor(NaN) do not appear to be defined in Standard
Haskell.
(They both come down to "properFraction" which is only defined for
Ratio.)
This differs from (for example) the Standard ML Basis Library, where it
is specified that floor(Int) should raise Overflow and floor(NaN) should
raise Domain. Hence Hugs and GHC do different things.
Hugs returns floor(Inf) = 0 and floor(NaN) = 0
GHC returns floor(Inf) = very very large integer and floor(NaN) = even
larger
integer. (This is because the GHC implementation of properFraction
simply
ignores the case of Inf/NaN and treats the artificially high exponent
encoded
in those floatingpoint numbers as if it were a real one.)
My own opinion is that Standard ML is right here and that floor(x)
should
raise an exception (In Haskell terms, fail) when x does not correspond
to a
real number.
 Original Message
 From: glasgowhaskellusersbounces at haskell.org
[mailto:glasgowhaskellusers
 bounces at haskell.org] On Behalf Of Sven Panne
 Sent: 08 August 2004 17:02
 To: Hal Daume III
 Cc: GHC Users Mailing List; Malcom Wallace
 Subject: Re: Double > CDouble, realToFrac doesn't work

 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.

 _______________________________________________
 Glasgowhaskellusers mailing list
 Glasgowhaskellusers at haskell.org
 http://www.haskell.org/mailman/listinfo/glasgowhaskellusers
More information about the Glasgowhaskellusers
mailing list