Double -> CDouble, realToFrac doesn't work

[Sven Panne]

It's an old thread, but nothing has really happened yet, so I'd like to
restate and expand the question: What should the behaviour of toRational,
fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report
is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on something.
Can we agree on the special Rational values below?

Printing those values could be more consistent for these systems, too, BTW.

Cheers,
    S.

Simon Peyton-Jones wrote:
> | 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.uni-bremen.de] 
> Sent: 25 February 2000 10:19
> To: glasgow-haskell-users at haskell.org
> Subject: Floating-point 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 floating-point 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: glasgow-haskell-users-bounces at haskell.org
> [mailto:glasgow-haskell-users-
> | 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.
> | 
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users at haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
>