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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
