[Numpy-discussion] Extensive use of methods instead of functions

'José Fonseca' j_r_fonseca at yahoo.co.uk
Fri Jan 24 15:21:02 EST 2003

On Fri, Jan 24, 2003 at 12:34:54PM -0800, Paul F Dubois wrote:
> Every time the subject of subclassing a numeric array comes up, it as
> if nobody ever thought of it before.

Why do you treat me as if I was trying to sell the "Next Big Thing"!?

First, I must tell you that the first time I came across the idea of
subclassing Numeric arrays was while reading the "Subclassing"
subsection, in the "Special Topics" section of the Numeric Python
manual. Your name, Paul, appears as one of the authors.

Second, subclassing Numeric arrays may be useful. Again, the
distribution of Numeric Python even has one big example: making a linear
algebra oriented version of Numeric python, where the operations would
be the standard matrix and vector operations instead of the element-wise
> Been there, done that.  It doesn't turn out to be all that useful. 

As seen by the examples above is obvious you did. Still, I don't see how
can you possibly say it isn't useful...

> To see why, consider a + b where a and b are Foo instances, and Foo
> inherits from numarray.
> a. a + b will be a numarray, not a Foo instance, unless you write a
> new + operator.  b. Attempting to have numarray itself apply a
> subclass constructor to the result runs into the problem that numarray
> does not have any idea what the constructor's signature is or what
> information is needed to fill out that constructor.  c. Even if the
> subclass accepts numarray's constructor signature, it would rarely
> produced satisfactory results just "losing" the Foo'ness details of a
> and b.
> This same argument applies to every method that returns a Foo
> instance, and every ufunc. So you end up redoing everything anyway.

[In general it may be usefully to subclass Numeric arrays if one just
want to add/overload methods, but no new properties.]

And third, if you read my thread you'd notice that the use of methods
instead of functions has implications/benefits much beyond the
subclassing issue. It's particularly important for Numeric-alike arrays. 

All objects in Python are virtual so you don't actually need to subclass
to use different kind of objects in the same piece as code.

While you're right in the sense that for many practical applications
there is little use of subclassing - a sparse matrix class is one of
them for instance -, you can't deny that is quite useful to have
Numeric-alike arrays, in the same basis as is currently done with the
file-alike objects in Python, i.e., they could be strings, web pages but
as long as they define a set of methods, these.

> In short, worrying about subclassing is way down the list of things we
> ought to consider. 

If so, then why did your comment only focused on the subclassing issue?
The subclassing was a mere introduction [perhaps unfortunate, I confess]
to the method overloading issue.  Now, if you could (re)read my first
post and comment on my actual suggestion I would appreciate.

Of course that I have no problems if the Numeric/numarray maintainers
decide to turn it down. I'll most probably just use UserArray.py to create a
"method-ized" version of Numeric, so that my algorithms can work with
both Numeric array and sparse matrices. (I do have a real case need of
for this.)

BTW, there is an alternative to create full-methodized Numeric array:
just add a attribute which points to the module which the class belongs,
e.g., "myarray.module.take" would point to "Numeric.take" if it was a
Numeric array, or "Sparse.take" if it was a sparse matrix.


José Fonseca
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

More information about the NumPy-Discussion mailing list