-------- 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.
participants (1)
-
Colin J. Williams