[Haskell-cafe] Why is toRational a method of Real?

John Meacham john at repetae.net
Thu Aug 5 07:11:34 EDT 2010

On Thu, Aug 05, 2010 at 11:35:04AM +0200, Henning Thielemann wrote:
> Why should realToFrac do this? NaN, Infinity and +/-0 are IEEE hacks for  
> the common numerical applications you do with floating point numbers.  
> These special values could be supported by floating point specific, or  
> even IEEE specific type classes, but they should not be part of  
> mathematically motivated type classes .

Because IEEE floating point values are both extremely useful in practice
and generally map exactly onto the underlying hardware implementation.
Proper support for them is very useful and allows an efficient
implementation of the language.

>> and the rounding functions discard information too by trying to convert 
>> a floating point value to an integral one...
> What else shall a rounding function return if not integers?

The same type that was passed in, round NaN should be NaN for instance,
and they should be implementable by the underlying hardware primitive.
the rounding functions have IEEE specified behavior but the current
classes inhibit actually implementing them properly.

>> I was probably going to introduce a 'FloatMax' type in jhc that is
>> guarenteed to be able to represent all values representable by native
>> floating point types, then replace the use of Rational as an
>> intermediate type with it.. not that that helps things right now really.
> Integer and Rational represent all possible integers and rationals,  
> respectively, apart from memory restrictions. They are not very 
> efficient, but that's why GHC's optimizer rules replace common 
> conversions by more efficient conversions.

But the problem is that it doesn't replace them with more efficient
conversions, it replaces them with code that behaves differently,
whether a RULE fires can dramatically affect the behavior of code, this
is because the functions specified by the haskell report don't actually
map to the fast hardware primitives we want to use and have available to
use. This isn't to say ghc is doing the wrong thing, I don't think there
really is a right thing to do here given the broken class specifications
in the report.


John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

More information about the Haskell-Cafe mailing list