realToFrac issues
Jacques Carette
carette at mcmaster.ca
Tue Feb 28 13:41:35 EST 2006
John Meacham 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.
>
>
If the point is to allow floating-point conversion to go through Ratio
correctly, you might have to do that.
However, I would think long and hard before actually doing this. We
tried exactly this in Maple (introduce -0 in the rationals, after having
implemented fully IEEE-754 floats/doubles/etc), and that broke the
system in a huge number of weird ways that we could not hope to 'fix' in
a sensible manner. So we backed that one change out (ie this was
implemented internally, and the resulting system was completely broken
for about a month as we tried to make sense of the resulting mess, then
backed it out).
My current belief is that floats are such a "non algebraic" (from a
mathematical point of view) type that it is hopeless to try to get it to
inter-operate with algebraic types (ie Fractional/Ratio). So realToFrac
will necessarily lose information. Now, given realToFrac, the sign of a
real number, isNaN, and isInfinity, one *can* construct an algebraic
representation which will be complete, but it will have to contain more
information than can be coded in a Fractional object.
What *problem* are you actually trying to solve here? If it is
"conversion between floating point types", then there are other
solutions that do not need to ``pollute'' exact arithmetic. I did not
see any tickets on this -- did I miss it/them? This is one issue where
I should go and contribute, as I've been part of a team that has done
just this to a programming language before, so at least I can claim to
know the pitfalls to avoid!
Jacques
More information about the Haskell-prime
mailing list