On Thu, 5 Aug 2010, Ivan Lazar Miljenovic wrote:

On 5 August 2010 10:15, Lennart Augustsson wrote:

...

You're right.  It's bad to have toRational in Real.  It's also bad to have Show and Eq as superclasses to Num.

I understand why it's bad to have Show as a superclass, but why Eq? Because it stops you from using functions as numbers, etc. ?

Yes, and on lazy computable reals (==) is not defined for numbers that are equal.

On Thu, Aug 5, 2010 at 11:35 AM, Henning Thielemann wrote:

What else shall a rounding function return if not integers?

Getting from 29.84645 to 29.85 isn't rounding ? David.

On Thu, 5 Aug 2010, David Virebayre wrote:

On Thu, Aug 5, 2010 at 11:35 AM, Henning Thielemann wrote:

...

What else shall a rounding function return if not integers?

Getting from 29.84645 to 29.85 isn't rounding ?

Sure, it is, I missed that. Maybe such rounding functions are not provided in Prelude because, say, rounding to a certain number of decimal places cannot be computed exactly with binary floating point numbers.

Henning Thielemann writes:

On Wed, 4 Aug 2010, John Meacham wrote:

...

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?

Some people may wish to a certain number of decimal places instead. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

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 -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

On Thu, 5 Aug 2010, David Virebayre wrote:

On Thu, Aug 5, 2010 at 1:11 PM, John Meacham wrote:

...

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.

I often read that the numerical classes are problematic. At the same time, there are many programs and packages that rely on Haskell being that way.

I think the numeric type classes of Haskell 98 are better than the way of handling numbers in most other existing languages. They are ok for the applications that do not need polymorphic numeric types.

What would it take to redesign the numeric class so that the new design eventually becomes the new Haskell standard ? ( not just an alternative prelude ) Is it doable at all ? Would a first step be trying to compile all of hackage with the numeric prelude and see what breaks ?

Almost nothing would compile, because the organization is too different, not to speak of the more mathematically oriented names of the classes.

If it's doable, how many years would it take to make it happen ?

All functions that use polymorphic numeric types would have to be adapted. However it would be a great test case for a refactoring tool! It's even worse: The NumericPrelude is in progress, certainly currently better than Haskell 98's type classes, but there are known problems. Sometimes new numeric types are implemented and require to refine or restructure the classes, again. And there are not only problems with the numeric type classes, think of Functor, Applicative, Monad, and so on. In my opinion before trying to move to an improved numerical type hierarchy we should have class aliases designed, implemented and thoroughly tested in GHC.

On Thu, 5 Aug 2010, David Virebayre wrote:

It's sad because the class alias proposal was dropped from Haskell' two years ago, isn't it ?

I don't know, but I think before an extension can go into Haskell' it should be at least implemented somewhere. (Is it implemented in JHC at all?)

Henning Thielemann wrote:

On Wed, 4 Aug 2010, John Meacham wrote:

...

The numeric classes are sort of messed up when it comes to non integral values. (not that they are perfect for other things) for instance, realToFrac doesn't preserve NaN or Infinity,

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 .

If we assume +/-Infinity, then NaN comes along too--- unless you want pure expressions to throw exceptions whenever messing with infinities in the wrong way. Silent exceptional values are evil, but throwing exceptions willy nilly is even more evil. You could argue that including the limits of the type as values in the type is wrong, but it does allow for some nice mathematics like log 0 = -Inf. -- Live well, ~wren