Extensive use of methods instead of functions
With the ability of subclassing types in recent versions of the Python language, more people will be interested in subclassing Numeric arrays for specific purposes. Still the use of functions instead of methods takes away many of the advantages, the ability of being overloaded. Taking this statement as an example: Numeric.put(myarray, myindices, myvalues) In the current state of affairs, if we wanted to have to statment to work with asparse matrix class derived from a Numeric array, it would have to be something like: Sparse.put(myarray, myindices, myvalues) That is, it forces to the underlaying code to know whether is dealing with Numeric arrays, or some other equivalent class. But it would be much more useful to have simply: myarray.put(myindices, myvalues) which would work regardless of the actual type of myarray, provided it supplied the put() method. This would improve enormously code reusability and extensability. I know that there are certain implementations details that may difficult this (like many functions being implemented in pure Python), but any advances made in this since will be an improvement of the current situation. Also, I know that this example is a little unhappy because numarray will do these things with the __getitem__ and __setitem__ operators. But others could easily be shown. Regards, José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
José Fonseca <j_r_fonseca@yahoo.co.uk> writes:
With the ability of subclassing types in recent versions of the Python language, more people will be interested in subclassing Numeric arrays for specific purposes. Still the use of functions instead of methods takes away many of the advantages, the ability of being overloaded.
True. On the other hand, there is also an advantage: NumPy routines can be used on standard Python data types such as number and sequence types. In the ideal world (which might come one day), core NumPy functionality would be part of standard Python, and then all these operations would work on other built-in types as well. Until then, I am not sure that changing NumPy functions to methods is a good idea. I need to call them on scalar numbers much more often than I subclass arrays. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
Every time the subject of subclassing a numeric array comes up, it as if nobody ever thought of it before. Been there, done that. It doesn't turn out to be all that 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 short, worrying about subclassing is way down the list of things we ought to consider.
-----Original Message----- From: numpy-discussion-admin@lists.sourceforge.net [mailto:numpy-discussion-admin@lists.sourceforge.net] On Behalf Of Konrad Hinsen Sent: Friday, January 24, 2003 12:07 PM To: José Fonseca Cc: numpy-discussion@lists.sourceforge.net Subject: Re: [Numpy-discussion] Extensive use of methods instead of functions
José Fonseca <j_r_fonseca@yahoo.co.uk> writes:
With the ability of subclassing types in recent versions of the Python language, more people will be interested in subclassing Numeric arrays for specific purposes. Still the use of functions instead of methods takes away many of the advantages, the ability of being overloaded.
True. On the other hand, there is also an advantage: NumPy routines can be used on standard Python data types such as number and sequence types.
In the ideal world (which might come one day), core NumPy functionality would be part of standard Python, and then all these operations would work on other built-in types as well.
Until then, I am not sure that changing NumPy functions to methods is a good idea. I need to call them on scalar numbers much more often than I subclass arrays.
Konrad. -- -------------------------------------------------------------- ----------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------- -----------------
------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Paul Dubois writes:
Every time the subject of subclassing a numeric array comes up, it as if nobody ever thought of it before. Been there, done that. It doesn't turn out to be all that 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 short, worrying about subclassing is way down the list of things we ought to consider.
Paul illustrates some important points. While I'm not as down on the ability to subclass (more on that later), he is absolutely right that most think that subclassing is a breeze and don't realize that it is far from being so. The arguments for this would be helped immensely by a practical example of a desired subclass. This does far more to illustrate the issues than an abstract discussion. For most instances that I have considered or thought about it is unavoidable that one must override virtually all (if not all) the operators and functions. Nevertheless, subclassing can still save a great deal of work over implementing a completely new extension. But you'll have to deal with defining how all the operators and functions should behave. In our view, the most valuable subclassing in numarray comes from subclassing NDArray, which handles all the structural operations for arrays (recarray makes heavy use of this). But recarrays don't try to support numerical operations, and that makes it fairly easy. Subclassing numarrays is significantly more work for the reasons cited. Perry
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 operations.
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. Regards, José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
On Fri, 24 Jan 2003, [iso-8859-15] 'José Fonseca' wrote:
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.)
Sparse matricies are common enough that they really should be a base part of Numeric rather than requiring subclassing/extending/etc. I know that Travis O. was working on some sparse matrix stuff a while back so you might want to contact him to get the current status of that work. -a
On Fri, Jan 24, 2003 at 09:07:21PM +0100, Konrad Hinsen wrote:
José Fonseca <j_r_fonseca@yahoo.co.uk> writes:
With the ability of subclassing types in recent versions of the Python language, more people will be interested in subclassing Numeric arrays for specific purposes. Still the use of functions instead of methods takes away many of the advantages, the ability of being overloaded.
True. On the other hand, there is also an advantage: NumPy routines can be used on standard Python data types such as number and sequence types.
In the ideal world (which might come one day), core NumPy functionality would be part of standard Python, and then all these operations would work on other built-in types as well.
Until then, I am not sure that changing NumPy functions to methods is a good idea. I need to call them on scalar numbers much more often than I subclass arrays.
You've got a good point there. I often want to use with other Numeric array-alike classes, but I've also used them with standard Python data types for convenience. Still, it's perfectly possible to both interfaces to co-exist. Of course that when one would use the .method version it can't expect to work with standard Python data types and has to make a choice, or to use asarray() or something equivalent before using it. Regards, José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
participants (6)
-
'José Fonseca' -
Andrew P. Lentvorski, Jr. -
José Fonseca
-
Konrad Hinsen -
Paul F Dubois -
Perry Greenfield