[SciPy-user] Using NumArray to facilitate Matrix arithmetic

[Colin J. Williams]

-------- Original Message --------

[Perry Greenfield]

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

[Colin W.
>>> 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.
>

[Perry Greenfield]

 I'm not sure what this comment refers to. If it is important, can you
be more explicit about the inhibition regarding subclasses?

[Colin W.]

I feel that it could be important and will try to put together an
illustrative example over the next week or so.  There are a number
of functions in the package which might, with benefit, be replaced
with methods of NumArray.  Such methods could then be inherited by
any sub-classes.  In the case of a possible Matrix class, there are
some functions/methods which my be represented, in a more user
friendly way by class properties.

For example, in matrix algebra, one typically represents transpose
with a superscript T or an inverse with a superscript -1.

Using properties, we could use A.T or B.I to represent the transpose
or the inverse of matrices A and B respectively.

These are not new ideas. Huaiyu Zhu started implementing them in 
his MatPy project.

[Eric Jones]
 >> 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...
>

[Colin W.]
This notion of being able to write mathematics like code is at the
root of this.

Suppose that A is a Matrix and B is an array, then

A + B ==> a matrix, with coercion, is not that much different from 
          array operations.

A * B ==> a matrix is similar but the multiplication implies the 
          operation of linear algebra, rather than a simple element 
          by element multiplication.

If we wished to find the common norm for A, it is a little simpler 
to write A.Norm than to write A.Norm(), using a method or Norm(A),
for a function.

[Perry Greenfield]
 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).

[Colin W.]
Let's look at each of these:
  Overriding:  Yes, that's a chore, but a boiler plate could be 
               prepared for the class and then be used by each
               sub-class builder.
  Less work:   The sub-class constructor is largely riding on
               the back of the class builder.  Labour saving is
               one of the potential benefits of the object
               oriented approach.
  An example:  Since Huaiyu Zhu was working largely with Numeric,
               he could not sub-class.  The latest version of
               Matrix.py that I've seen is of 26-Aug-01.
               I'll put a simple illustrative example together.

[Colin W.]
> 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?
>

[Perry Greenfield]
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.

[Colin W.]
I agree that interoperability with other numarray modules 
and packages is essential and doubt that very much would 
need to be changed in NumArray to facilitate inheritance.

For some, the idea of element by element operations takes 
a little getting use to.  For multi-dimensional arrays, it
is the only way to go.  For two dimensional array, there
could well be a choice, which the user makes by choosing
to work with a NumArray class or a Matrix class.  The
latter is based on an extensive literature which has grown
over that last 50 and more years.

It would seem to be mutually beneficial to have these 
classes from the same root.

[Perry Greenfield]
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.

[Colin W]
It would be nice if there were more functional characters 
available on the keyboard.  However, groupings of characters 
to achieve operations on particular data types would 
complicate Python and would not likely appeal to our
BDFL.

The idea of operator overloading is already well established
for Python.

[Colin W]
>>> 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.

[Eric Jones]
>>>
>>> Don't know much about this.


[Colin W]
>>> 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 have been made.
>

[Perry Greenfield]
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.

[Colin W.]
> 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.
>

[Perry Greenfield]
numarray? The latest version should be 0.5 (and 0.6 will be released
very shortly).

[Colin W.]
No, my comments here were with regard to MatPy.
Please see: http://matpy.sourceforge.net/
The last change appears to be about August 2001.