[SciPy-user] Matrix Arithmetic

[Perry Greenfield]

I haven't had much time to respond to these comments and queries,
but I'll do my best.

> Behalf Of Colin J. Williams
> From: "eric jones" <eric at enthought.com>
> [snip]
>
>>> numarray appears to be largely operable, but speed problems have been
>>> reported. NDArray and NumArray are the basic classes of numarray, but
>>>
>>> the
>>>
>>> design decision seems to have been made to deprecate the use of class
>>> methods in favour of factory functions.  This appears to inhibit the
>>> development of sub-classes to NumArray.
>
I'm not sure what this comment refers to. If it is important, can you
be more explicit about the inhibition regarding subclasses?
>
>> Not sure what this is about because I haven't followed it that closely,
>> but I will say that sub-classing arrays isn't all that it is cracked up
>> to be in practice.  One of the nicest things about arrays is there array
>> arithmetic. They allow you to write mathematic formula-like code for
>> numerical operations.  When you sub-class an array, say with an Image
>> class, all mathematic operations work, but they return arrays instead of
>> images -- not so nice.  You end up having to do a lot of work to get the
>> behavior you want from the sub-classing.  I'm not saying it isn't
>> occasionally useful, it just isn't as nice as it first sounds...
>
My 2 cents on subclassing: It isn't useless, but it is rarely trivial.
Eric is right that most subclassing involves overriding all the operators
and that will generally involve some work. On the other hand, subclassing is
generally far more preferable to writing your own stuff from scratch (I'm
guessing anyway). But on the third hand, outside of the customizations
referred
to below, I haven't seen a good practical example of subclassing numeric
arrays
yet so I can't comment on how useful it is yet (not to say we won't
eventually
come up with some).

> I have been looking at the sub-classing of NumArray to provide matrix
> arithmetic, along
> the lines of  Huaiyu Zhu, but not quite as ambitious.
>
> So that A + B, A * B, A  /  B all make sense, where A and B are matrices.
>
> Similarly A.T delivers the transpose of A or B.I delivers the
> inverse of B.
>
> Does anyone have any thoughts?
>
> Colin W.
>
Yes, I do. Doing this would be (relatively) easy. But it would be
wrong (IMHO). If you do this, you will break interoperability with
other numarray modules and packages. There will be lots of code that
will assume that * means element-by-element multiplication, not matrix
multiplication. So by doing this you in effect will be fracturing the
numeric community. If the judgement is that there is very little shared
code (e.g., FFT, signal processing, linear algebra, etc.) between the
two, little harm would be done. I tend to think that isn't the case.
Now one has to wrap these modules to work with the matrix arrays, or
if there are matrix modules available, then they have to be wrapped to
work with numarray.

I'd rather see one of the proposals to allow extending operator syntax to
allow defining new Python operators so that matrix multiplication and
the small number of other matrix operations can be accomodated rather
than making incompatible types of arrays/matrices. I believe Guido will
accomodate this should enough of the community make a case for it.

>
>>> MatPy is an effort to facilitate matrix operations.  It seems to have
>>> resulted from a lot of work by Huaiyu Zhu.  An extended discussion
>>>
>>> took
>>>
>>> place during 2000 to 2001, but there seems to be little current
>>>
>>> interest.
>
>> Don't know much about this.
>
>
> The project was originally based on Numeric, but appears to be in
> transition to
> numarray.  Again, the decision to use factory functions, rather than
> exploiting
> the full capability of the Python class structure, appears to hav been
>
> made.
>
Again, not sure what this refers to. Also, I'm not aware of any work that
that Huaiyu is doing with regard to this or numarray recently.

> Source Forge advertises the availability of version 0.4 as a
>
> downloadable
>
> Win 32 package, but it seems to have regressed to version 0.3.
>
numarray? The latest version should be 0.5 (and 0.6 will be released
very shortly).


Perry Greenfield