On 02-Aug-1998, Jan Skibinski <[EMAIL PROTECTED]> wrote:
>
> I've been recently working on yet another Haskell server, and when
> testing its safety limits on numerical examples, I realized that
> there are several quite annoying problems with Haskell numerical
> types and classes.
>
> + Many library functions, which operate on Int, return value 0
> or faulty negative values on overflow condition. Since there
> is no exception mechanism built into Haskell,
Yes, that is a problem; but I hear that people are working on it.
For an indication of what the solution will look like, see the
recent long discussion about exceptions on this mailing list.
> + Hugs is supplied with the type Number. According to its
> author: "Fixed width integers with overflow detection..
...
> My comment is that the chosen name "Number" is here a very
> unfortunate choice:
I strongly agree here.
> + Haskell extension libraries define a bunch of Word types.
> An attempt to show that Haskell can be numerically efficient?
Sure, why not?
> + Although Prelude numeric classes are well designed from point
> of view of classification, the abundance of numeric classes
> makes them difficult to use
It's hard for a single design to satisfy everyone, I suppose.
If you have concrete suggestions on how to make them easier to use,
by all means speak up.
> + Yet again - as it has happened with other languages, someone
> has decided that complex numbers are somehow not as important
> as other numbers.
Seems eminently reasonable to me. Complex numbers are NOT as
important for the vast majority of users. Furthermore,
complex numbers can easily be implemented using records
and the basic numerical types, whereas the basic numerical
types cannot be implemented efficiently using other language
constructs.
> At least Haskell acknowledges that they exist,
> yet they are relegated to a periferial library - an icing on
> a cake.
Exactly where the should be, IMHO.
> But anyone working in physics or engineering would tell you
> otherwise: complex numbers are very important in daily usage.
So those people should use that library!
How hard is it to write "import Complex"?
> However, class Complex in Haskell is tied up to Floating numbers,
> just beacuse other classes, such as Rational, do not know how to
> take square roots or deal with trigonometry, exponentials or
> hyperbolics.
>
> But where on Earth it is said that the domain of Complex numbers
> should be restricted to Float or Double? Why not Rationals as
> well?
This is a legitimate criticism. It might well make sense to have
a complex number package that supports such types.
Of course, no-one is stopping you from writing such a package ;-)
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
