[Haskell] Re: Numeric programming on toy problems in Haskell
Simon PeytonJones
simonpj at microsoft.com
Wed Sep 12 16:38:41 EDT 2007
Interesting though this thread is, it belongs on Haskellcafé, or ghcusers, not the main Haskell announcement list. Can I suggest that replies are directed to one of those places?
Simon
 Original Message
 From: haskellbounces at haskell.org [mailto:haskellbounces 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 fglasgowexts
 #}, 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
 > unstall this ;)

 That is *a lot* more complicated. Beware of nontermination. 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 turingcomplete 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