Hi Fergus:
>
> How hard is it to write "import Complex"?
>
Not hard at all, but I think I did not make myself
clear in my previous post. Here is the clarification:
One of the benefits of having Complex closely coupled
with other numbers is its potential utilization
in error handling. So far, evaluation of sqrt (-1)
produces unrecoverable error. But the answer could
be the legal complex 0:+1 - providing that the instance
(-1) (currently Floating a) knows about Complex.
For the sake of the argument, I assume here that
in some revised version of Haskell there is a class
Number, and the operation sqrt is defined as:
sqrt :: Number -> Number
sqrt x =
if isComplex x then
sqrtComplex x
else if (x < 0) then
0:+sqrtReal (-x)
else
sqrtReal (x)
This implies that Complex and other numbers are equal
partners in the world of numbers. But that would require
that the entire hierarchy of numbers should be somehow
revised.
Not only sqrt, but a bunch of other functions could be
rescued in a similar way:
log (-1)
asin (4/3) - currently interpreted as Floating, produces NaN
acos (4/3)
etc.
The problem is not new at all. I think that a typical
approach to incorporating Complex into a typical library
in a typical language is as follows:
1. Initial design stage:
Complex? Who cares, it is not that important!
2. Later:
Someone discovers that Complex might be useful,
so a library is written as an add-on. However,
in some languages this is already too late,
because the library implementation cannot be
made efficient and would require some support from
the language itself. Example: Eiffel.
Let me describe what happened with Eiffel. One day
Bertrand Meyer realized that in order to find a wider
audience they must prove that Eiffel is perfectly suitable
for scientific/engineering applications, and is not
just a general purpose language - as you have put
it in your message.
For this they needed a mathematical library. They
decided to build an object oriented interface to
the existing NAG library - C version. Suddenly
they "discovered" the world of complex numbers, because
a majority of NAG functions from linear algebra
and from nonlinear equations produce complex answers.
Say you want to find the eigenvalues of Real matrix.
If the matrix is square and symmetric than the eigenvalues
are real, otherwise they are complex.
Say you want to find roots of some polynomial.
You start with real coefficients, but in many cases
you end up with complex roots. Real roots are just
a special case.
Eiffel is a strongly typed language. By the time
we started the project (I am a co-designer of
the Mathematical Library for Eiffel, Paul Dubois was
the project leader) it already had a very elaborate
hierarchy of numbers. Suddenly there was a problem: how
to fit complex into the scheme of things, how to handle
two types of answers in the same time.
We did not have much choice and our complex numbers had
to be limited to the Double domain. That's why I am trying
to warn you about this issue - before it's too late.
We managed, but it was not so easy. I do not work
with Eiffel any more, but if you search for my
name in association with Eiffel you will come across
some critique of my portion of the design. Some
people even like it.:-)
In summary:
-----------
Anyone can design a complex number library. The task is
not much more complex (pun intended:-) than dsigning
the type Point.
What is difficult though is to make Complex a citizen
of the world of existing numbers.
Jan
