[PYTHON MATRIX-SIG] Why I won't add complex numbers to the base language
Hinsen Konrad
hinsenk@ere.umontreal.ca
Thu, 14 Sep 1995 12:42:21 -0400
1. Mathematically, there is at least one difference: complex numbers
can't be compared (e.g. z1 < z2 is undefined when either has a nonzero
imaginary party). Python will have to define this operation anyhow,
So that would lead to an exception. Nothing exceptional ;-), since
there are other operations that produce exceptions (like division
by zero).
-- but it leads me to believe that there should be plenty of
algorithms out there that wouldn't work if some of their parameters
were complex numbers. (At least if the designer of the code didn't
think about the possibility of complex numbers, the correctness of the
code can't be guaranteed in general.) As long as real and complex are
True, but the same problem occurs with complex numbers defined in
packages. Since Python's variables and function parameters are not
types, nothing prevents me from passing complex numbers to an
algorithm not designed for them.
2. The available of GNU or other pseudo-free packages for
transcendental functions on complex numbers is still a big restriction
for Python's portability. Everything that is part of the *core*
language has to be portable to every new platform. Since some of
That should not be a problem. All codes for complex numbers that
I am aware of handle complex-number arithmetic in terms of (portable)
real arithmetic. An implementation of complex numbers in portable C
is just as possible as in portable Python.
another problem with GNU code that's only relevant for a certain group
but which I care about anyway: people want to be able to embed Python
(at least it's core) in commercial applications, and if there's a GNU
licence attached to any part of that core, this is a problem. (Don't
There are non-GNU complex libraries, and even writing a new one is
only a small task.
3. The implementation of complex numbers as the only floating-point
type in Python would add considerable complexity (no pun intended :-).
I take that this should mean that if x is a real number (e.g. 0.0) and
z is a complex number (e.g. sqrt(-1.0)), type(x) == type(z). This
Indeed.
means that the representation in memory of Python complex number
objects either has to contain the imaginary part at all times, or it
has to contain a flag telling whether there's an imaginary part or
Maybe. I don't know much about the internals of Python, I am just a
simple user... But I know that most APL implementation use different
internal types, but don't make this distinction visible to the user.
In fact, they don't even distinguish between integers and reals.
APL has only two types: character and numeric, although numeric
has four internal representations (bits, integers, reals, and complex
numbers).
Consider the alternative: write an extension module ("complex") that
defines arithmetic on complex numbers (there are already examples of
how to do this in Python; a C version is totally plausible) and
another extensions module ("cmath") that defines transcendental
functions on complex number. Now the price is only paid by those who
That would indeed be a good solution (I come to like Python's module
system more and more every day). I'll explore that when I find some
time... I don't see any real problem, everything necessary for
a convenient implementation should be there (i.e. coercion from
realfloat to complex, such that real constants can be entered
conveniently). It would be nice to have a more convenient notation
for complex constants, but that is not really essential.
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca
Departement de chimie | Tel.: +1-514-343-6111 ext. 3953
Universite de Montreal | Fax: +1-514-343-7586
C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/
Montreal (QC) H3C 3J7 | Francais (phase experimentale)
-------------------------------------------------------------------------------
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================