Python linear algebra module -- requesting comments on interface

[C. Barnes]

Hi, I'm in the process of writing a Python linear
algebra module.

The current targeted interface is:

http://oregonstate.edu/~barnesc/temp/linalg/

The interface was originally based on Raymond
Hettinger's
Matfunc [1]. However, it has evolved so that now it
is
nearly identical to JAMA [2], the Java matrix library.

I am soliticing comments on this interface.

Please post up any criticism that you have. Even
small
things -- if something isn't right, it's better to fix
it now than later.

I have not made source code available yet, since the
current code is missing the decompositions and doesn't
match the new interface. I'm in the process of
rewritting the code to match the new interface. You
can e-mail me and ask for the old code if you're
curious
or skeptical.

[1]. http://users.rcn.com/python/download/python.htm
[2]. http://math.nist.gov/javanumerics/jama/

---------------------------------------------
Brief comparison with Numeric
---------------------------------------------

Numeric and linalg serve different purposes.

Numeric is intended to be a general purpose array
extension. It takes a "kitchen sink" approach,
and includes every function which could potentially
be useful for array manipulations.

Linalg is intended to handle real/complex vectors
and matrices, for scientific and 3D applications.
It has a more restricted scope. Because it is
intended for 3D applications, it is optimized
for dimension 2, 3, 4 operations.

For the typical matrix operations, the linalg
interface is much intuitive than Numeric's. Real
and imaginary components are always cast to
doubles, so no headaches are created if a matrix
is instantiated from a list of integers. Unlike
Numeric, the * operator performs matrix
multiplication, A**-1 computes the matrix inverse,
A == B returns True or False, and the 2-norm and
cross product functions exist.

As previously stated, linalg is optimized for
matrix arithmetic with small matrices (size 2, 3, 4).

A (somewhat out of date) set of microbenchmarks [3]
[4]
show that linalg is roughly an order of magnitude
faster than Numeric for dimension 3 vectors and
matrices.

[3].
Microbenchmarks without psyco:
http://oregonstate.edu/~barnesc/temp/
numeric_vs_linalg_prelim-2005-09-07.pdf

[4].
Microbenchmarks with psyco:
http://oregonstate.edu/~barnesc/temp/
numeric_vs_linalg_prelim_psyco-2005-09-07.pdf



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

 

[Volker Grabsch]

Hi, I'm in the process of writing a Python linear
algebra module.

The current targeted interface is:
http://oregonstate.edu/~barnesc/temp/linalg/

Is this going to become free software. If yes, what license
will you use?


So my suggestions:

In cases like these ones:

random_matrix(m, n=-1)
zero_matrix(m, n=-1)

... I think it's better to set the default value to "None"
instead of a number:

random_matrix(m, n=None)
zero_matrix(m, n=None)

IMHO, this is more intuitive and more "pythonic".

I also suggest to make the "random function" choosable:

random_matrix(m, n=None, randfunc=random.random)
random_vector(n, randfunc=random.random)

This way it's more easy for those who want another range
of numbers, or want another kind of distribution of the
random numbers.


At the top of your documentation, there is a link "overview",
which is broken:

See _overview_ for a quick start.


Greets,

Volker

 

[Martin Miller]

Since one of the module's targeted applications is for 3D applications,
I think there should be some specific support for applying the
Matrix-vector product operation to a sequence of vectors instead of
only one at a time -- and it should be possible to optimize the
module's code for this common case.

I'd also like to see some special specific errors defined and raised
from the Matrix det(), inverse(), and transpose() methods when the
operation is attempted on an ill-formed matrices (e.g. for non-square,
non-invertible, singular cases). This would allow client code to handle
errors better.

Very nice work overall, IMHO.

Best,
-Martin

 

[Colin J. Williams]

Connelly,

Apologies, my first message was sent in error.

I like your general setup. You appear to permit matrix operations,
which the folk at Numeric and, later, numarray did not.

My own package, PyMatrix, has similar aims to yours but it may be slower
as it is based on numarray.

My package is just about ready for another release but I'm toiling to
improve the documentation. I felt that it could be of value to
newcomers to matrices and so my new documentation is more long-winded
than yours. Your overview sets the whole thing out very neatly.

I have made use of Python's properties for transpose, inverse etc. This
uses abbreviations and avoids redundant parentheses.

My work was based on the ideas of Huaiyu Zhu, who developed MatPy:
http://matpy.sourceforge.net/

You might be interested in looking at PyMatrix:
http://www3.sympatico.ca/cjw/PyMatrix/

Best wishes,

Colin W.

Hi, I'm in the process of writing a Python linear
algebra module.

The current targeted interface is:

http://oregonstate.edu/~barnesc/temp/linalg/

The interface was originally based on Raymond
Hettinger's
Matfunc [1]. However, it has evolved so that now it
is
nearly identical to JAMA [2], the Java matrix library.

I am soliticing comments on this interface.

Please post up any criticism that you have. Even
small
things -- if something isn't right, it's better to fix
it now than later.

I have not made source code available yet, since the
current code is missing the decompositions and doesn't
match the new interface. I'm in the process of
rewritting the code to match the new interface. You
can e-mail me and ask for the old code if you're
curious
or skeptical.

[1]. http://users.rcn.com/python/download/python.htm
[2]. http://math.nist.gov/javanumerics/jama/

---------------------------------------------
Brief comparison with Numeric
---------------------------------------------

Numeric and linalg serve different purposes.

Numeric is intended to be a general purpose array
extension. It takes a "kitchen sink" approach,
and includes every function which could potentially
be useful for array manipulations.

Linalg is intended to handle real/complex vectors
and matrices, for scientific and 3D applications.
It has a more restricted scope. Because it is
intended for 3D applications, it is optimized
for dimension 2, 3, 4 operations.

For the typical matrix operations, the linalg
interface is much intuitive than Numeric's. Real
and imaginary components are always cast to
doubles, so no headaches are created if a matrix
is instantiated from a list of integers. Unlike
Numeric, the * operator performs matrix
multiplication, A**-1 computes the matrix inverse,
A == B returns True or False, and the 2-norm and
cross product functions exist.

As previously stated, linalg is optimized for
matrix arithmetic with small matrices (size 2, 3, 4).

A (somewhat out of date) set of microbenchmarks [3]
[4]
show that linalg is roughly an order of magnitude
faster than Numeric for dimension 3 vectors and
matrices.

[3].
Microbenchmarks without psyco:
http://oregonstate.edu/~barnesc/temp/
numeric_vs_linalg_prelim-2005-09-07.pdf

[4].
Microbenchmarks with psyco:
http://oregonstate.edu/~barnesc/temp/
numeric_vs_linalg_prelim_psyco-2005-09-07.pdf



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

 

[Bengt Richter]

Hi, I'm in the process of writing a Python linear
algebra module.

The current targeted interface is:

http://oregonstate.edu/~barnesc/temp/linalg/

The interface was originally based on Raymond
Hettinger's
Matfunc [1]. However, it has evolved so that now it
is
nearly identical to JAMA [2], the Java matrix library.

I am soliticing comments on this interface.

Please post up any criticism that you have. Even
small
things -- if something isn't right, it's better to fix
it now than later.

Wondering whether you will be supporting OpenGL-style matrices and
operations for graphics. UIAM they permit optimizations in both
storage and operations due to the known zero and one element values
that would appear in full matrix representations of the same.

http://www.rush3d.com/reference/opengl-redbook-1.1/appendixg.html

Also wondering about some helper function to measure sensitivity of
..solve results when getting near-singular, but maybe that's an
out-side-of-the package job.

From a quick look, it looks quite nice ;-)

Regards,
Bengt Richter

 

[Szabolcs Nagy]

nice interface, but with 3d apps i prefer cgkit's approach, which has
vec3, vec4, mat3, mat4 and quat types with lots of useful functions for
3d graphics (like mat4.looakAt(pos, target, up) or mat3.toEulerXYZ())

there are other libs with similar types and functions:
cgkit (http://cgkit.sourceforge.net/)
pyogre (http://www.ogre3d.org/wiki/index.php/PyOgre)
panda3d (http://panda3d.org/)