[Haskell] Re: Numeric programming on toy problems in Haskell

Simon Peyton-Jones simonpj at microsoft.com
Wed Sep 12 16:38:41 EDT 2007


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 at haskell.org [mailto:haskell-bounces at haskell.org]
| On Behalf Of Isaac Dupree
| Sent: 12 September 2007 15:37
| To: haskell at 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/haskell


More information about the Haskell mailing list