[PYTHON MATRIX-SIG] LAPACK module questions
Doug Heisterkamp
drh@oasis.unl.edu
Tue, 13 Feb 1996 16:57:21 -0600 (CST)
>
> 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.
I assume that the caller knows the structure of the storage methods and
packs it into an python array object. I have not used these functions
yet (I really just started to use the Lapack library), but they seem to
want one or two dimensional arrays with specific information at certain
locations. The low-level access module assumes this has already been
done for the objects passed to it. A higher level access module would
be useful in setting up these structures.
>
> 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.
>
<snip>
>
> 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.
I agree.
>
> 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.
What is a "generalized inverse"? If I remember correctly, the generalized
eigenvalue problem is (A - lambda C)x = 0 where C is a matrix. But I don't
remember running across a generalized inverse.
>
> 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.
I hope so as the Fortran libraries should be faster.
Doug
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================