Re: Numeric programming on toy problems in Haskell
Dear Isaac, all,
Integral looks reasonable (are those really supposed to be div and mod in defining quotRem, not quot and rem? I'm not sure).
Yes, you're right. I changed to quot and rem. Also, the denominator and numerator functions were a bit needlessly complex.
There's no(?) excuse for using GHC extensions... just use (Prelude.)fromRational instead of GHC.Float.fromRat (if using GHC, it will optimize to the same thing, at least if optimizations are on); and remove {-# OPTIONS -fglasgow-exts #-}.
You were right about fromRat. I changed it into fromRational, saving me a GHC specific import. The GHC extensions are used, however, because of laziness; i.e. automatic derivation of Enum, Num, Fractional, Real and RealFrac. Without the GHC extensions, only Eq and Ord can be derived automatically. If I'm wrong about this, please let me know, because I would prefer a compiler independent solution as well. With respect to optimization; I think considering optimizability (?) in the design of such a module is a bit of a paradox. If optimization is a criterion, use the fine-grained typing and don't chuck all your numeric types into a single Number type.
(Have you seen Scheme's (dynamically typed) numeric ladder? It adds a separate, additional concept of being able to tell, from a numeric value, whether it is exact or not - e.g. for this Number implementation, (1 + 1/3) is exact, and (sin pi) isn't, I think.)
No, I haven't, I'm afraid. Like I said, this was pretty much a quick'n'dirty solution so that I could get on with my little puzzles (and because I learned FP in Miranda and never quite lost the 'num' affinitiy). There is a lingering idea that I could / should rework the Floating and RealFloat instances to be arbitrarily precise for most functions, by using continued fractions (only works for continued fractions that show regularity). Another option I was considering was to have all those operations be represented symbolically until such a time when they really needed to be approximated (for show, toInteger or toFloat). At that time I could either have my own simplifier and approximator, or I could link to other tools (maple, gnu something?). The idea was stalled, because I only use this for toy problems ;) If someone feels inspired, feel free to take this module and rework. I'm also open for suggestions on how to do this myself in case I ever un-stall this ;) Regards, Philip PS. Version with minor revisions is available, again from: http://www.cs.utwente.nl/~holzensp/Number.hs
Philip K.F. Hölzenspies wrote:
The GHC extensions are used, however, because of laziness; i.e. automatic derivation of Enum, Num, Fractional, Real and RealFrac. Without the GHC extensions, only Eq and Ord can be derived automatically. If I'm wrong about this, please let me know, because I would prefer a compiler independent solution as well.
Thank you for reminding me. You can preferably use {-# LANGUAGE GeneralizedNewtypeDeriving #-} instead of {-# OPTIONS -fglasgow-exts #-}, to just enable the needed extension, although only GHC implements it currently.... Or, you can explicitly write out each instance in the very straightforward way, which is portable (though a bit annoying and inefficient). Or, I think there are tools that can automatically write such instances for you?
[...] At that time I could either have my own simplifier and approximator, or I could link to other tools (maple, gnu something?).
The idea was stalled, because I only use this for toy problems ;) If someone feels inspired, feel free to take this module and rework. I'm also open for suggestions on how to do this myself in case I ever un-stall this ;)
That is *a lot* more complicated. Beware of non-termination. I don't think every equality, every exactness, is observable (not sure whether a Num type like that offers the full power of the real numbers - if it does, then you have a turing-complete problem.) Whereas, the present inexactness means that the numerator and denominator don't tend to get so big that the computations are really slow. (If MPFR could be used in Haskell, one could choose the desired precision rather than using whatever Double gives, I suppose) Making the type be "data" with fields Rational as well as whether it's exact, could be done (though I'm not entirely satisfied with, nor interested in, the "exact" concept, so it's just an idea). Then you would not be able to use generalized newtype deriving, so you wouldn't ^_^ Isaac
Interesting though this thread is, it belongs on Haskell-café, or ghc-users, not the main Haskell announcement list. Can I suggest that replies are directed to one of those places? Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] | On Behalf Of Isaac Dupree | Sent: 12 September 2007 15:37 | To: haskell@haskell.org | Subject: [Haskell] Re: Numeric programming on toy problems in Haskell | | Philip K.F. Hölzenspies wrote: | > The GHC extensions are used, however, | > because of laziness; i.e. automatic derivation of Enum, Num, | > Fractional, Real and RealFrac. Without the GHC extensions, only Eq | and | > Ord can be derived automatically. If I'm wrong about this, please let | > me know, because I would prefer a compiler independent solution as | > well. | | Thank you for reminding me. You can preferably use {-# LANGUAGE | GeneralizedNewtypeDeriving #-} instead of {-# OPTIONS -fglasgow-exts | #-}, to just enable the needed extension, although only GHC implements | it currently.... Or, you can explicitly write out each instance in the | very straightforward way, which is portable (though a bit annoying and | inefficient). Or, I think there are tools that can automatically write | such instances for you? | | | > [...] | > At that time I could either have my own simplifier and | > approximator, or I could link to other tools (maple, gnu something?). | > | > The idea was stalled, because I only use this for toy problems ;) If | > someone feels inspired, feel free to take this module and rework. I'm | > also open for suggestions on how to do this myself in case I ever | > un-stall this ;) | | That is *a lot* more complicated. Beware of non-termination. I don't | think every equality, every exactness, is observable (not sure whether | a | Num type like that offers the full power of the real numbers - if it | does, then you have a turing-complete problem.) | | Whereas, the present inexactness means that the numerator and | denominator don't tend to get so big that the computations are really | slow. (If MPFR could be used in Haskell, one could choose the desired | precision rather than using whatever Double gives, I suppose) | | Making the type be "data" with fields Rational as well as whether it's | exact, could be done (though I'm not entirely satisfied with, nor | interested in, the "exact" concept, so it's just an idea). Then you | would not be able to use generalized newtype deriving, so you wouldn't | ^_^ | | Isaac | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell
participants (3)
-
Isaac Dupree -
Philip K.F. Hölzenspies -
Simon Peyton-Jones