[PYTHON MATRIX-SIG] Who wants to test my complex number module?

Hinsen Konrad hinsenk@ere.umontreal.ca
Fri, 3 Nov 1995 13:54:51 -0500


   a. It is a surprising thing (to me) that while tan is in the Fortran standard,
      cot isn't. We put one in Basis because it drove us crazy.

I haven't ever had a pressing need for cot(), but since it costs
virtually nothing to add such simple functions, there is little
reason not to do so. I already added the inverse hyperbolic functions
to my cmath module, because it seemed silly not to have them.
I am perfectly willing to add more functions, also to the float
math module.

This leads to the question of what functions would be desirable. In
addition to the full set of angular functions, I'd like to see the
error function and the gamma function. Anything else?

   b. The conjugation function in Fortran is called conjg, not conj.
      We probably should have a functional equivalent, too, conjg(c).
      Actually, the conjugate not really an attribute of the object,
      it is a transform, and so I'd rather see a method which conjugates
      the given object and a conjg(c) which returns copy(c).conjg().

I had already expected that objection. In fact the only reason why I
implemented conjugation as an attribute (which indeed it should not
be) is that I didn't want to add functions to the complex module.  I
envisioned that maybe one day one could make complex numbers a
standard part of Python, like floats, with their proper input
notation, and then there would be no more complex module. It could be
put into cmath, but it doesn't really belong there. I am open to any
suggestion on where to put this function...

      1. Abbreviations should be avoided. Basically, if you don't abbreviate
	 you can't forget which abbreviation to use. So in the immediate case,

That is also the position of Mathematica, and it works well in
practice. The only "safe" abbreviations are those long established in
mathematical notation, like "sin" or "log". On the other hand, does
anyone really want SquareRoot()? Even Mathematica uses Sqrt[].  I
think one needs a certain (very small) set of accepted abbreviations.
The point is not just ease of typing, but also keeping moderately
complex expressions short enough to be legible.

	 the reusable software library. (Although, you can make a case that
	 conjg isn't an abbreviation, it is the Fortran name which everyone
	 knows!)

I'd rather not make the assumption that everyone knows Fortran! In fact,
I'd be happy if I could one day forget Fortran.

   e. About the printed representation of a complex: shouldn't it be 
      complex(1.0, 1.1) not 1j1.1 ? There are two components to this thought.

For my taste complex(1.0,1.1) is too long, especially in matrices.

      One is that the two parts should be presented with equal precision.

Why? I find 3.1415926j0 much nicer than 3.1415926j0.0000000 (and shorter
too).

      Second is that it might come in handy if the printed form was readable
      back into Python, and there seems to be some "tradition" of this sort

Of course. My hope is that the output notation I use (which by the way
is stolen from APL2 and J) could become the accepted input notation
one day.

      of convention in Python components already. The Fortran representation
      for code literals is (1.0, 1.1) which is also suggestive.

But it can never become an input notation, since (1.0, 1.1) is read
as a tuple in Python. Even for output only it would be confusing.

For flexible output, there should be some kind of formatting option,
as it exists for floating point numbers. But that can't be implemented
in a module, so it doesn't exist for now.

   f. Note to ourselves: the printing of large matrices needs to be more 
      orderly and labeled.

Definitely. Again APL is a good example to copy.

   Basis> real x = ones(5, 20)
   Basis> x
   x                  shape: (5,20)
    row col =         1             2             3             4
    1:            1.00000E+00   0.00000E+00   0.00000E+00   0.00000E+00
    2:            0.00000E+00   1.00000E+00   0.00000E+00   0.00000E+00
    3:            0.00000E+00   0.00000E+00   1.00000E+00   0.00000E+00
    4:            0.00000E+00   0.00000E+00   0.00000E+00   1.00000E+00
    5:            0.00000E+00   0.00000E+00   0.00000E+00   0.00000E+00
   ...

I am not sure I'd like this to be the default output format.
The labels are nice for big matrices, but for small matrices
I'd prefer just the elements. Also, I'd prefer non-exponential
notations as long as it is reasonable for all elements (as in
this case).

APL systems tend to choose the optimal output format based
on many properties of the matrix, and I have really come
to appreciate that. Unfortunately, J doesn't follow this
tradition.

-------------------------------------------------------------------------------
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. Centre-Ville     | 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
=================