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