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