realToFrac issues

[Cale Gibbard]

On 28/02/06, John Meacham <john at repetae.net> wrote:
> On Tue, Feb 28, 2006 at 12:44:04AM -0500, Cale Gibbard wrote:
> > I'm almost scared to ask: does this mean we need negative zero as well?
>
> good point. probably.
>
> > This change means that Rational is no longer a field. It makes me feel
> > uneasy at least. Should we really expect realToFrac to propagate those
> > values? Look at its type:
> > realToFrac     :: (Real a, Fractional b) => a -> b
> > Nothing about the Fractional class would seem to indicate that NaN and
> > +-Infinity should be representable. In fact, it just looks like the
> > basic field operations, and fields don't tend to have such elements
> > (not that we require the field axioms to hold for every instance).
>
> It makes me uneasy too. Perhaps we can come up with something better.
>
> > I personally don't see any reason that realToFrac should propagate the
> > special error condition values of IEEE floating point types. Given its
> > type, I'd expect it to throw an exception.
>
> well, the main reason is that it is the only way we have to convert
> between various floating point types. If we can come up with another
> mechanism then perhaps that is a better solution, but it is not at all
> obvious to me what that other mechanism would be.

How about,
toRealFloat :: (RealFloat a, RealFloat b) => a -> b
toRealFloat = uncurry encodeFloat . decodeFloat
Presently, this doesn't quite work, but that's due to the inability of
encodeFloat to produce pairs which mean NaN and -0. If we extend its
codomain a bit to include those, that would seem fine. It would seem
to me that if we want a conversion between IEEE floating point types,
then it should be somewhere around here in the hierarchy anyway.

 - Cale