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

Isaac Dupree isaacdupree at charter.net
Wed Sep 12 10:37:02 EDT 2007


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


More information about the Haskell mailing list