realToFrac issues

[Jacques Carette]

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