[PYTHON MATRIX-SIG] LAPACK module questions

[Konrad HINSEN]

   I have completed a first pass at a C module to access the LAPACK library.  I

Great!

   have a few questions as I move on an try to refine it.  But first, what I've
   done is to write a parser that reads the source code from CLAPACK and writes
   an access call for each function.  The name and parameters are the same as in
   the library with the exception of using the array object for matrices and
   vectors.

Not bad for a low-level access module; some people are familiar with
these names and will probably want to use them. I just wonder what you
do with the routines for special storage methods (banded, packed
symmetric, etc.); they don't make any sense in Python.

   How should I package this C module with a python module?  Should it become
   a subclass of Matrix or UserArray?  Should it be a module with just a bunch
   of functions in it?

I'd say the latter. I have thought a bit about how the current array
operations and extensions such as linear algebra can best be combined
and used with a consistent access scheme. I have come to the conclusion
that the best solution is to have only functions in various modules
for all mathematical and structural operations, and use methods only
for special stuff like typecode inquiries.

This proposal is certainly somewhat surprising for true believers in
object-oriented programming, but I'll argue that it is still the best
compromise. The alternative in a true object-oriented spirit would be
to implement most (if not all) operations as methods on array objects.
For extensions like linear algebra, one would define a subclass of
arrays with added methods. Someone who wants to use several such
extensions, e.g. linear algebra and fft, would then create another
class inheriting both from linear-algebra-arrays and fft-arrays.

There are three problems with this approach, one specific to Python,
and two generic. The Python-specific problem is that one cannot
inherit from C types, and that C types cannot inherit from
anything. That would make a Python wrapper for all array classes
obligatory, with a resulting performance penalty (mostly noticeable
for small arrays).

One of the generic problems (at least in languages without type
checking) is that mixing different array classes causes a lot of
headaches. If some library returns an fft-array and someone want to
use it as a linear-algebra-array, then it has to be converted
first. This would be worst for the standard constructors, like
zeros(), whose results could not be used in any derived module.

The other generic problem is caused by the relatively many operations
that depend symmetrically on more than one object. It doesn't really
make sense to consider an addition as an operation on the first number
with the second as parameter, and this is basically what causes all
the coercion problems for binary operators that Python suffers from.
I am not saying that a more sensible approach is impossible (one could
for example define addition as an operation on a tuple of numbers),
but I am not aware of any language that supports this in a clean way.

The best way out in Python is, in my opinion, not to implement any
operation as a method. That leads to a clean system without confusion,
and Python's module system takes care of name space pollution. It may
be old-fashioned, but it works.

   Are there other people working on accessing math libraries?  It would be nice
   if we could set up some conventions on function names, calling parameters, 
   and exceptions for some of the common items.  That way code that needs, say

Definitely. Still all I personally need is LAPACK...

   I'm planning on writing a python wrapper for eigenvectors, determinants,
   and svd.  What other functions are commonly used and would be nice to
   have a clean interface to (as compared to the fortran interface of the
   lapack library)?

Inverse, generalized inverse, and solution of linear equations.  As a
second step, generalized eigenvalue problems and linear equations with
iterative refinement.

   If people are interested in the module, I could place it on an ftp server
   somewhere.  It currently uses libraries built from CLapack which are just

Yes, please!

   the f2c conversion of the original fortran source.  Elf binaries of the

Great, so one should be able to substitute the Fortran library
easily.

-------------------------------------------------------------------------------
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
=================