[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


   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

   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