On 28/02/06, John Meacham <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime