On 28/12/2007, Christopher Barker <Chris.Barker@noaa.gov> wrote:
Anne Archibald wrote:
Numpy provides ufuncs as general powerful tools for operating on matrices. More can be added relatively easily, they provide not just the basic "apply" operation but also "outer" and others. Adding another way to accomplish the same operation just adds bulk to numpy.
Maybe so, but if it were up to me, I'd have just the methods, and not the functions -- I like namespaces and OO design. I've always thought it was a spurious argument that these kinds of functions can operate on things that aren't numpy arrays -- it's true, but they all return arrays, to it's not like they really are universal.
It doesn't make a whole lot of sense to me to have n-ary methods (though I don't think we currently have any ternary ufuncs). How would you accomodate all the other operations ufuncs support? The big problem with methods, it seems to me, is that if I want to add a new ufunc, it's relatively easy. In fact, with vectorize() I do that all the time (with all sorts of arities). But adding compiled ufuncs in a new module is relatively straightforward; it's not at all clear how a separate package could ever add new methods to the ndarray object. This is not hypothetical - scipy.special introduces many mathematical functions that either are or should be ufuncs. As for whether this is "object-oriented", well, ufuncs are objects with a variety of methods; one could productively inherit from them (at least in principle, though I've never had occasion to). Anyway, I don't know that we need to rehash the old discussion. I just wanted to point out the value of ufuncs as objects. Anne