Re: [Haskell-cafe] Why is toRational a method of Real?
On Thu, 5 Aug 2010, Ivan Lazar Miljenovic wrote: On 5 August 2010 10:15, Lennart Augustsson lenn...@augustsson.net 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.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
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 . 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? 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On Thu, Aug 5, 2010 at 11:35 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: What else shall a rounding function return if not integers? Getting from 29.84645 to 29.85 isn't rounding ? David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
Henning Thielemann lemm...@henning-thielemann.de 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.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On 05.08.2010 13:35, 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 . But they are. isNaN, isInfinite, isNegativeZero are all members of RealFloat type class and there is no generic for type conversion which conserves NaNs. Numeric type classes are really messed up. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
David Virebayre dav.vire+hask...@gmail.com writes: On Thu, Aug 5, 2010 at 11:35 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: What else shall a rounding function return if not integers? Getting from 29.84645 to 29.85 isn't rounding ? Yes it is: http://en.wikipedia.org/wiki/Rounding Usually, however, we often just want to round something to an integral value. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
Yes, for instance to be able to use functions as number. Or to be able to use constructive real numbers as numbers, since equality is not computable. -- Lennart On Thu, Aug 5, 2010 at 4:17 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 5 August 2010 10:15, Lennart Augustsson lenn...@augustsson.net 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. ? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On Thu, 5 Aug 2010, David Virebayre wrote: On Thu, Aug 5, 2010 at 11:35 AM, Henning Thielemann lemm...@henning-thielemann.de 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On Thu, Aug 5, 2010 at 1:11 PM, John Meacham j...@repetae.net 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. 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 ? If it's doable, how many years would it take to make it happen ? Just curious. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On Thu, 5 Aug 2010, David Virebayre wrote: On Thu, Aug 5, 2010 at 1:11 PM, John Meacham j...@repetae.net 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On Thu, Aug 5, 2010 at 1:55 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: 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. It's sad because the class alias proposal was dropped from Haskell' two years ago, isn't it ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
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?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
It's sad because the class alias proposal was dropped from Haskell' two years ago, isn't it ?Haskell' is an ongoing process of language revision. ClassAliases did not get into Haskell 2010, but it could certainly be adopted in 2011 or 2012, if there were consensus support for it. Usually, proposals also need to have been implemented in practice in at least one compiler, to demonstrate their feasibility (that compiler need not always be ghc :-).Here is the haskell' ticket for ClassAliases: http://hackage.haskell.org/trac/haskell-prime/ticket/101And John Meacham's detailed proposal: http://repetae.net/recent/out/classalias.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/5/10 05:47 , David Virebayre wrote: On Thu, Aug 5, 2010 at 11:35 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: What else shall a rounding function return if not integers? Getting from 29.84645 to 29.85 isn't rounding ? It is, but it's also easy to achieve given round-to-integer. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxa1j0ACgkQIn7hlCsL25UKfQCggmZID1fCQ6VuqysRp4eAGtk2 K8MAmwWstczYxKVEQzDUZghXTy8aMkYM =f4L6 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On Aug 4, 2010, at 11:30 AM, Omari Norman wrote: Why is toRational a method of Real? I thought that real numbers need not be rational, such as the square root of two. Wouldn't it make more sense to have some sort of Rational typeclass with this method? Thanks. You can't build the real number field using a computer. So you have to turn what should be a real into something you can express on a computer. You can either choose to use the field of computable real numbers, which is slow, or you can just go with a near enough rational approximation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
You're right. It's bad to have toRational in Real. It's also bad to have Show and Eq as superclasses to Num. On Wed, Aug 4, 2010 at 8:30 PM, Omari Norman om...@smileystation.com wrote: Why is toRational a method of Real? I thought that real numbers need not be rational, such as the square root of two. Wouldn't it make more sense to have some sort of Rational typeclass with this method? Thanks. --Omari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On Wed, Aug 04, 2010 at 02:30:10PM -0400, Omari Norman wrote: Why is toRational a method of Real? I thought that real numbers need not be rational, such as the square root of two. Wouldn't it make more sense to have some sort of Rational typeclass with this method? Thanks. 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, except on ghc when optimization is turned on. and the rounding functions discard information too by trying to convert a floating point value to an integral one... 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. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
Why is toRational a method of Real? I thought that real numbers need not be rational, such as the square root of two. Wouldn't it make more sense to have some sort of Rational typeclass with this method? I think everyone has problems with the Haskell numeric typeclasses. The answer in this case is that - toRational DOES make sense for every instance of Real in the Haskell98 Report and Libraries, because that basically means floating point numbers, and floating point numbers are rationals (if you allow 1/0, -1/0, and 0/0 you've covered infinities and NaNs) - the designers don't seem to have included any layers that weren't needed for the tasks immediately at hand, after all, Haskell was supposed to avoid success, and the language went through several revisions quite quickly. - but then the wind changed and her face WAS frozen like that... http://www.haskell.org/haskellwiki/Numeric_Prelude shows what _can_ be done in Haskell. Making it possible to work with alternatives to parts of the standard Prelude was a very far-sighted design decision. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On 5 August 2010 10:15, Lennart Augustsson lenn...@augustsson.net 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. ? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
