# Python linear algebra module -- requesting comments on interface

Discussion in 'Python' started by C. Barnes, Sep 9, 2005.

1. ### C. BarnesGuest

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.

[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

C. Barnes, Sep 9, 2005

2. ### Volker GrabschGuest

C. Barnes wrote:
> 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"

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.

which is broken:

See _overview_ for a quick start.

Greets,

Volker

--
Volker Grabsch
---<<(())>>---
\frac{\left|\vartheta_0\times\{\ell,\kappa\in\Re\}\right|}{\sqrt
[G]{-\Gamma(\alpha)\cdot\mathcal{B}^{\left[\oint\!c_\hbar\right]}}}

Volker Grabsch, Sep 9, 2005

3. ### Martin MillerGuest

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

Martin Miller, Sep 9, 2005
4. ### Colin J. WilliamsGuest

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.

C. Barnes wrote:
> 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.
>
> [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

Colin J. Williams, Sep 9, 2005
5. ### Bengt RichterGuest

On Fri, 9 Sep 2005 04:58:43 -0700 (PDT), "C. Barnes" <> wrote:

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

Bengt Richter, Sep 10, 2005
6. ### Szabolcs NagyGuest

Szabolcs Nagy, Sep 11, 2005