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