[Numpy-discussion] adding a .M attribute to the array.

[Konrad Hinsen]

a.schmolck at gmx.net (A.Schmolck) writes:

> Linear algebra functionality is currently exclusively provided by `array` and
> libraries that operate on and return `array`s, but the computational and
> notational efficiency leaves to be desired (compared to e.g. Matlab) in some
> areas, importantly matrix multiplications (which are up to 40 times slower)
> and really awkward to write (and much more importantly, decipher afterwards).

Computational and notational efficiency are rather well separated,
fortunately. Both the current dot function and an hypothetical matrix
multiply operator could be implemented in straightforward C code or
using a high-performance library such as Atlas. In fact, this should
even be an installation choice in my opinion, as installing Atlas
isn't trivial on all machines (e.g. with some gcc versions), and I
consider it important for fundamental libraries that they work
everywhere easily, even if not optimally.

> My impression is that the best path also very much depends on the what the
> feature aspirations and divisions of labor of numpy/numarray and scipy are
> going to be. For example, scipy is really aimed at scientific users, which
> need performance, and are willing to buy it with inconvenience (like the

I see the main difference in distribution philosophy. NumPy is an
add-on package to Python, which is in turn used by other add-on
packages in a modular way. SciPy is rather a monolithic
super-distribution for scientific users.

Personally I strongly favour the modular package approach, and in fact
I haven't installed SciPy on my system for that reason, although I
would be interested in some of its components.

> algorithms, without doing any numerical computations on the arrays). So maybe
> (a subset of) numpy should make it into the python core (or an as yet

This has been discussed already, and it might well happen one day, but
not with the current NumPy implementation. Numarray looks like a much
better candidate, but isn't ready yet.

> In such a scenario, where numpy remains relatively general (and
> might even aim at incorporation into the core), it would be a no-no
> to bloat it with too much code aimed at improving efficiency
> (calling blas when possible, sparse storage etc.). On the other hand

The same approach as for XML could be used: a slim-line version in the
standard distribution that could be replaced by a high-efficiency
extended version for those who care.

> attractive solution do incorporate good matrix functionality (and
> possibly other improvements for hard core number crunchers) in scipy
> only (or at least limit the efficient _implementation_ of matrices
> to scipy, providing at only a pure python class or so in numpy). I'm

I'd love to have efficient matrices without having to install the
whole SciPy package!

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------