Please chime in on proposed methods for arrays
One item I have not received a lot of feedback on is the new proposal for a greatly increased number of methods on the ndarray. The current PEP has a listing of all the proposed methods and attributes (some more were added after consulting current numarray in more detail and looking at all the functions in current Numeric.py) If a function call essentially involved an arrayobject with some other parameters then it was turned into a method. If it involved two "equal" arrays then it was left as a function. This is a somewhat arbitrary convention, and so I am asking for suggestions as to what should be methods. Should all the ufuncs be methods as well? I think Konrad suggested this. What is the opinion of others? The move from functions to methods will mean that some of the function calls currently in Numeric.py will be redundant, but I think they should stay there for backwards compatibility, (perhaps with a deprecation warning...) A final question: I think we need to think carefully about multidimensional indexing so that it replaces current usage of take, put, putmask. For example, how, in numarray would you replace take(a,[1,5,10],axis=-2) if a is a 10x20x30 array? Note that in this case take returns a 10x3x30 array (call it g) with g[:,0,:] = a[:,1,:] g[:,1,:] = a[:,5,:] g[:,2,:] = a[:,10,:] I submit that a[...,[1,5,10],:] would be an appropriate syntax. This would mean changing the current PEP a bit. -Travis
Travis Oliphant wrote:
Should all the ufuncs be methods as well? I think Konrad suggested this. What is the opinion of others?
Just to make sure I understand the proposal correctly. Does this mean that
anotherarray = sin(myarray) becomes anotherarray = myarray.sin() ?
--Michiel.
Michiel Jan Laurens de Hoon wrote:
Travis Oliphant wrote:
Should all the ufuncs be methods as well? I think Konrad suggested this. What is the opinion of others?
Just to make sure I understand the proposal correctly. Does this mean that
anotherarray = sin(myarray) becomes anotherarray = myarray.sin() ?
Or even myarray.Sin?
--Michiel.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Travis Oliphant wrote:
One item I have not received a lot of feedback on is the new proposal for a greatly increased number of methods on the ndarray.
The current PEP has a listing of all the proposed methods and attributes (some more were added after consulting current numarray in more detail and looking at all the functions in current Numeric.py)
If a function call essentially involved an arrayobject with some other parameters then it was turned into a method. If it involved two "equal" arrays then it was left as a function. This is a somewhat arbitrary convention, and so I am asking for suggestions as to what should be methods.
Should all the ufuncs be methods as well? I think Konrad suggested this. What is the opinion of others?
I'm too lazy to search right now, but I'm pretty sure that Konrad suggested the opposite: that x.sin(), while possibly "cleaner" in an OO-fetishistic sense, jars too much against the expectation of sin(x) that all of us got accustomed to in math class. Maybe I should let him speak for himself, though. :-) I think the division you have listed in the PEP is a reasonable one. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Quoting Robert Kern <rkern@ucsd.edu>:
Travis Oliphant wrote:
Should all the ufuncs be methods as well? I think Konrad suggested this. What is the opinion of others?
I'm too lazy to search right now, but I'm pretty sure that Konrad suggested the opposite: that x.sin(), while possibly "cleaner" in an OO-fetishistic sense, jars too much against the expectation of sin(x) that all of us got accustomed to in math class. Maybe I should let him speak for himself, though. :-)
I certainly cringe at the sight of its_a.sin(). One of the advantages of python is that it doesn't impose any one methodology for software development: while an OO approach may be great for allowing arbitrary function-like objects to be callable, for example, it doesn't mean that everything under the sun has to become a method call. And, though I'm as lazy as Robert (in fact, I've proven to be lazier than him in the past), my memory also tells me that Konrad's mathematical sensibilities lean in the direction of sin(x). Best, f
On 17.03.2005, at 06:08, Robert Kern wrote:
I'm too lazy to search right now, but I'm pretty sure that Konrad suggested the opposite: that x.sin(), while possibly "cleaner" in an OO-fetishistic sense, jars too much against the expectation of sin(x) that all of us got accustomed to in math class. Maybe I should let him speak for himself, though. :-)
I agree. What I suggested is that there should be methods as well as functions, and that the ufuncs should call the methods, such that Numeric.sin(x) would simply become syntactic sugar for x.sin() whatever the type of x. But I don't expect to see x.sin() in application code, it's just a convenient way of implementing sin() in new classes and subclasses. Actually, x.__sin__() would be a more pythonic choice of method name. Konrad. -- ------------------------------------------------------------------------ ------- Konrad Hinsen Laboratoire Leon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen@cea.fr ------------------------------------------------------------------------ -------
On Mar 17, 2005, at 12:05 PM, konrad.hinsen@laposte.net wrote:
On 17.03.2005, at 06:08, Robert Kern wrote:
I'm too lazy to search right now, but I'm pretty sure that Konrad suggested the opposite: that x.sin(), while possibly "cleaner" in an OO-fetishistic sense, jars too much against the expectation of sin(x) that all of us got accustomed to in math class. Maybe I should let him speak for himself, though. :-)
I agree. What I suggested is that there should be methods as well as functions, and that the ufuncs should call the methods, such that
Numeric.sin(x)
would simply become syntactic sugar for
x.sin()
whatever the type of x. But I don't expect to see x.sin() in application code, it's just a convenient way of implementing sin() in new classes and subclasses. Actually, x.__sin__() would be a more pythonic choice of method name.
Konrad.
It would be hard to imagine not allowing the functional form. Users would think we were crazy. (And they'd be right ;-) Perry
On Thu, 17 Mar 2005, Perry Greenfield wrote:
On Mar 17, 2005, at 12:05 PM, konrad.hinsen@laposte.net wrote:
I agree. What I suggested is that there should be methods as well as functions, and that the ufuncs should call the methods, such that
Numeric.sin(x)
would simply become syntactic sugar for
x.sin()
whatever the type of x. But I don't expect to see x.sin() in application code, it's just a convenient way of implementing sin() in new classes and subclasses. Actually, x.__sin__() would be a more pythonic choice of method name.
Konrad.
It would be hard to imagine not allowing the functional form. Users would think we were crazy. (And they'd be right ;-)
I think the suggestion that ufuncs should call methods behind the scenes is a bad idea. It just doesn't makes much sense to me. Doesn't this imply that you have to decorate array objects with another method every time someone adds another 1-argument ufunc? Even if you argue that you only want the methods for some standard set of ufuncs, it seems like a lot of baggage to pile into the array objects. I like the arc hyperbolic sine function, but I can't see why I would expect an array to have either a method x.asinh() or, worse, x.__asinh__()! Maybe I'm misunderstanding something here, but this just sounds like a way to bloat the interface to arrays. Rick
Travis Oliphant wrote:
One item I have not received a lot of feedback on is the new proposal for a greatly increased number of methods on the ndarray.
The current PEP has a listing of all the proposed methods and attributes (some more were added after consulting current numarray in more detail and looking at all the functions in current Numeric.py)
If a function call essentially involved an arrayobject with some other parameters then it was turned into a method.
This seems a good idea. I would suggest going a step further. If a method has no parameters then make it a property and adopt the naming convention that the property names start with an upper case character, eg. Cos. In other words, drop the redundant parentheses.
If it involved two "equal" arrays then it was left as a function. This is a somewhat arbitrary convention, and so I am asking for suggestions as to what should be methods.
Why change from the above proposal?
Should all the ufuncs be methods as well? I think Konrad suggested this. What is the opinion of others?
Yes, modified as suggested above.
The move from functions to methods will mean that some of the function calls currently in Numeric.py will be redundant, but I think they should stay there for backwards compatibility, (perhaps with a deprecation warning...)
Yes, the same for numarray. Deprecation, with dropping from some future version.
A final question: I think we need to think carefully about multidimensional indexing so that it replaces current usage of take, put, putmask.
For example, how, in numarray would you replace take(a,[1,5,10],axis=-2) if a is a 10x20x30 array? Note that in this case take returns a 10x3x30 array (call it g) with
g[:,0,:] = a[:,1,:] g[:,1,:] = a[:,5,:] g[:,2,:] = a[:,10,:]
I submit that a[...,[1,5,10],:] would be an appropriate syntax. This would mean changing the current PEP a bit.
What is the benefit of the ellipsis here? It seems to serve the same purpose as the colon. Colin W.
-Travis
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
participants (8)
-
Colin J. Williams -
Fernando.Perez＠colorado.edu -
konrad.hinsen＠laposte.net -
Michiel Jan Laurens de Hoon -
Perry Greenfield -
Rick White -
Robert Kern -
Travis Oliphant