Adding .abs() method to the array object
![](https://secure.gravatar.com/avatar/468f182e9d98bb9d3545dd87faf5d8c2.jpg?s=120&d=mm&r=g)
Hello, i know that the array object is already crowded, but i would like to see the abs method added, especially doing work on the console. Considering that many much less used functions are also implemented as a method, i don't think adding one more would be problematic. greetings Till
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
My gut feeling is that we have too many methods on ndarray, not too few, but in any case, can you elaborate? What's the rationale for why np.abs(a) is so much harder than a.abs(), and why this function and not other unary functions? -n
![](https://secure.gravatar.com/avatar/ad13088a623822caf74e635a68a55eae.jpg?s=120&d=mm&r=g)
On Sat, Feb 23, 2013 at 3:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
my reason is that I often use arr.max() but then decide I want to us abs and need np.max(np.abs(arr)) instead of arr.abs().max() (and often I write that first to see the error message) I don't like np.abs(arr).max() because I have to concentrate to much on the braces, especially if arr is a calculation I wrote several times def maxabs(arr): return np.max(np.abs(arr)) silly, but I use it often and np.is_close is not useful (doesn't show how close) Just a small annoyance, but I think it's the method that I miss most often. Josef
![](https://secure.gravatar.com/avatar/09939f25b639512a537ce2c90f77f958.jpg?s=120&d=mm&r=g)
On Sat, Feb 23, 2013 at 8:20 PM, <josef.pktd@gmail.com> wrote:
My issue is having to remember which ones are methods and which ones are functions. There doesn't seem to be a rhyme or reason for the choices, and I would rather like to see that a line is drawn, but I am not picky as to where it is drawn. Ben Root
![](https://secure.gravatar.com/avatar/082c34b6c1544c177cb7a66609360089.jpg?s=120&d=mm&r=g)
On Sat, Feb 23, 2013 at 9:34 PM, Benjamin Root <ben.root@ou.edu> wrote:
I like that. I think it would be a good idea to find a good line for NumPy 2.0. As we already will break the API, why not break it for another part at the same time. I don't have any idea what would be a good line... Do someone have a good idea? Do you agree that it would be a good idea for 2.0? Fred
![](https://secure.gravatar.com/avatar/468f182e9d98bb9d3545dd87faf5d8c2.jpg?s=120&d=mm&r=g)
First, sorry that i didnt search for an old thread, but because i disagree with conclusion i would at least address my reason:
This exactly, adding an abs into an old expression is always a little annoyance due to the parenthesis. The argument that np.abs() also works is true for (almost?) every other method. The fact that so many methods already exists, especially for most of the commonly used functions (min, max, dot, mean, std, argmin, argmax, conj, T) makes me missing abs. Of course, if one would redesign the api, one would drop most methods (i am looking at you ptp and byteswap). But the objected is already cluttered and adding abs is imo logical application of "practicality beats purity". greetings Till
![](https://secure.gravatar.com/avatar/272540e56a9b1b5c01fa5ef3c7a91edd.jpg?s=120&d=mm&r=g)
On Mon, Feb 25, 2013 at 10:43 AM, Till Stensitzki <mail.till@gmx.de> wrote:
First, sorry that i didnt search for an old thread, but because i
disagree with
I tend to agree here. The situation isn't all that dire for the number of methods in an array. No scrolling at reasonably small terminal sizes. [~/] [3]: x. x.T x.copy x.getfield x.put x.std x.all x.ctypes x.imag x.ravel x.strides x.any x.cumprod x.item x.real x.sum x.argmax x.cumsum x.itemset x.repeat x.swapaxes x.argmin x.data x.itemsize x.reshape x.take x.argsort x.diagonal x.max x.resize x.tofile x.astype x.dot x.mean x.round x.tolist x.base x.dtype x.min x.searchsorted x.tostring x.byteswap x.dump x.nbytes x.setfield x.trace x.choose x.dumps x.ndim x.setflags x.transpose x.clip x.fill x.newbyteorder x.shape x.var x.compress x.flags x.nonzero x.size x.view x.conj x.flat x.prod x.sort x.conjugate x.flatten x.ptp x.squeeze I find myself typing things like arr.abs() and arr.unique() quite often. Skipper
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Feb 25, 2013 at 8:50 AM, Skipper Seabold <jsseabold@gmail.com>wrote:
Somehow, this reminds me of I. N. Hersteins book, Topics in Algebra<http://tinyurl.com/apoerwn>, where he did function composition left-to-right instead of right-to-left.
Herstein's attempt to revolutionise old algebraic habits never caught on. But it was a bold attempt ;) Chuck
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote:
Two small things (not sure if it matters much). But first almost all of these methods are related to the container and not the elements. Second actually using a method arr.abs() has a tiny pitfall, since abs would work on numpy types, but not on python types. This means that: np.array([1, 2, 3]).max().abs() works, but np.array([1, 2, 3], dtype=object).max().abs() breaks. Python has a safe name for abs already...
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Mon, 2013-02-25 at 22:04 -0500, josef.pktd@gmail.com wrote:
The difference is about scalars only. And of course __abs__ is fine, but if numpy adds an abs method, its scalars would logically have it too. But then you diverge from python scalars. That has exactly the downside that you may write code that suddenly stops working for python scalars without noticing. I turned around the abs and max order here, so that the abs works on the scalar, not useful but just as an example.
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Tue, 2013-02-26 at 11:16 +0100, Todd wrote:
I do not think that it does, or at a different quality. Almost all of those methods either logically work on the container not the array. I.e. reshape, etc. or are the most common reductions like mean/max/min (which are also only sensible for containers). Now those also work on numpy scalars but you should rarely use them on scalars. The only example I can see is round (there is no special method for that before python 3, so you could argue that python did not provide a canonical way for numpy). Now this is not a huge argument, obviously scalars can have a lot of specialized methods (like decimals for example), but in the case of abs, python provides a default way of doing it which always works, and it makes me tend to say that it is better to use that (even if I sometimes write .abs() too...).
![](https://secure.gravatar.com/avatar/a5c6e0b8f64a8a1940f5b2d367c1db6e.jpg?s=120&d=mm&r=g)
I'm hoping this discussion will return to the drawing the line question. http://stackoverflow.com/questions/8108688/in-python-when-should-i-use-a-fun... Alan Isaac
![](https://secure.gravatar.com/avatar/ad13088a623822caf74e635a68a55eae.jpg?s=120&d=mm&r=g)
On Tue, Feb 26, 2013 at 12:33 PM, eat <e.antero.tammi@gmail.com> wrote:
partially a joke. I don't see any good and simple rule to restrict the number of methods. dot was added as a method a few numpy versions ago, because it is painful to write nested or sequential dot products. Alan was in favor of the dot method and of matrix algebra because it's much easier on new users who come from a background that has a dot product as "*" or similar operator. As Skipper, I think the number of methods is not really huge (especially not numerical operations) Josef
![](https://secure.gravatar.com/avatar/ad13088a623822caf74e635a68a55eae.jpg?s=120&d=mm&r=g)
On Tue, Feb 26, 2013 at 1:11 PM, <josef.pktd@gmail.com> wrote:
99 was just the first number that came to mind that sounded exaggerated enough. (I like methods and will use __abs__ from now on, but I won't argue much in any direction of changes.) Josef http://en.wikipedia.org/wiki/99_Luftballons
![](https://secure.gravatar.com/avatar/a5c6e0b8f64a8a1940f5b2d367c1db6e.jpg?s=120&d=mm&r=g)
On 2/26/2013 1:11 PM, josef.pktd@gmail.com wrote:
Alan was in favor of the dot method
I still really like this, and it probably violates any simple rule for drawing the line. Nevertheless it would be nice to have some principle(s) other than the squeaky wheel principle for thinking about such proposals. Cheers, Alan
![](https://secure.gravatar.com/avatar/f14373168edcc55c5f2598a40de55c0d.jpg?s=120&d=mm&r=g)
Hi, Le 23/02/2013 20:25, Nathaniel Smith a écrit :
If x is a complex array, I feel that x.abs() and x.angle() would be natural complements to x.real and x.imag. Of course, x.angle() only make much sense for complex arrays while x.abs() makes sense for any numerical array. best, Pierre
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
My gut feeling is that we have too many methods on ndarray, not too few, but in any case, can you elaborate? What's the rationale for why np.abs(a) is so much harder than a.abs(), and why this function and not other unary functions? -n
![](https://secure.gravatar.com/avatar/ad13088a623822caf74e635a68a55eae.jpg?s=120&d=mm&r=g)
On Sat, Feb 23, 2013 at 3:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
my reason is that I often use arr.max() but then decide I want to us abs and need np.max(np.abs(arr)) instead of arr.abs().max() (and often I write that first to see the error message) I don't like np.abs(arr).max() because I have to concentrate to much on the braces, especially if arr is a calculation I wrote several times def maxabs(arr): return np.max(np.abs(arr)) silly, but I use it often and np.is_close is not useful (doesn't show how close) Just a small annoyance, but I think it's the method that I miss most often. Josef
![](https://secure.gravatar.com/avatar/09939f25b639512a537ce2c90f77f958.jpg?s=120&d=mm&r=g)
On Sat, Feb 23, 2013 at 8:20 PM, <josef.pktd@gmail.com> wrote:
My issue is having to remember which ones are methods and which ones are functions. There doesn't seem to be a rhyme or reason for the choices, and I would rather like to see that a line is drawn, but I am not picky as to where it is drawn. Ben Root
![](https://secure.gravatar.com/avatar/082c34b6c1544c177cb7a66609360089.jpg?s=120&d=mm&r=g)
On Sat, Feb 23, 2013 at 9:34 PM, Benjamin Root <ben.root@ou.edu> wrote:
I like that. I think it would be a good idea to find a good line for NumPy 2.0. As we already will break the API, why not break it for another part at the same time. I don't have any idea what would be a good line... Do someone have a good idea? Do you agree that it would be a good idea for 2.0? Fred
![](https://secure.gravatar.com/avatar/468f182e9d98bb9d3545dd87faf5d8c2.jpg?s=120&d=mm&r=g)
First, sorry that i didnt search for an old thread, but because i disagree with conclusion i would at least address my reason:
This exactly, adding an abs into an old expression is always a little annoyance due to the parenthesis. The argument that np.abs() also works is true for (almost?) every other method. The fact that so many methods already exists, especially for most of the commonly used functions (min, max, dot, mean, std, argmin, argmax, conj, T) makes me missing abs. Of course, if one would redesign the api, one would drop most methods (i am looking at you ptp and byteswap). But the objected is already cluttered and adding abs is imo logical application of "practicality beats purity". greetings Till
![](https://secure.gravatar.com/avatar/272540e56a9b1b5c01fa5ef3c7a91edd.jpg?s=120&d=mm&r=g)
On Mon, Feb 25, 2013 at 10:43 AM, Till Stensitzki <mail.till@gmx.de> wrote:
First, sorry that i didnt search for an old thread, but because i
disagree with
I tend to agree here. The situation isn't all that dire for the number of methods in an array. No scrolling at reasonably small terminal sizes. [~/] [3]: x. x.T x.copy x.getfield x.put x.std x.all x.ctypes x.imag x.ravel x.strides x.any x.cumprod x.item x.real x.sum x.argmax x.cumsum x.itemset x.repeat x.swapaxes x.argmin x.data x.itemsize x.reshape x.take x.argsort x.diagonal x.max x.resize x.tofile x.astype x.dot x.mean x.round x.tolist x.base x.dtype x.min x.searchsorted x.tostring x.byteswap x.dump x.nbytes x.setfield x.trace x.choose x.dumps x.ndim x.setflags x.transpose x.clip x.fill x.newbyteorder x.shape x.var x.compress x.flags x.nonzero x.size x.view x.conj x.flat x.prod x.sort x.conjugate x.flatten x.ptp x.squeeze I find myself typing things like arr.abs() and arr.unique() quite often. Skipper
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Feb 25, 2013 at 8:50 AM, Skipper Seabold <jsseabold@gmail.com>wrote:
Somehow, this reminds me of I. N. Hersteins book, Topics in Algebra<http://tinyurl.com/apoerwn>, where he did function composition left-to-right instead of right-to-left.
Herstein's attempt to revolutionise old algebraic habits never caught on. But it was a bold attempt ;) Chuck
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote:
Two small things (not sure if it matters much). But first almost all of these methods are related to the container and not the elements. Second actually using a method arr.abs() has a tiny pitfall, since abs would work on numpy types, but not on python types. This means that: np.array([1, 2, 3]).max().abs() works, but np.array([1, 2, 3], dtype=object).max().abs() breaks. Python has a safe name for abs already...
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Mon, 2013-02-25 at 22:04 -0500, josef.pktd@gmail.com wrote:
The difference is about scalars only. And of course __abs__ is fine, but if numpy adds an abs method, its scalars would logically have it too. But then you diverge from python scalars. That has exactly the downside that you may write code that suddenly stops working for python scalars without noticing. I turned around the abs and max order here, so that the abs works on the scalar, not useful but just as an example.
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Tue, 2013-02-26 at 11:16 +0100, Todd wrote:
I do not think that it does, or at a different quality. Almost all of those methods either logically work on the container not the array. I.e. reshape, etc. or are the most common reductions like mean/max/min (which are also only sensible for containers). Now those also work on numpy scalars but you should rarely use them on scalars. The only example I can see is round (there is no special method for that before python 3, so you could argue that python did not provide a canonical way for numpy). Now this is not a huge argument, obviously scalars can have a lot of specialized methods (like decimals for example), but in the case of abs, python provides a default way of doing it which always works, and it makes me tend to say that it is better to use that (even if I sometimes write .abs() too...).
![](https://secure.gravatar.com/avatar/a5c6e0b8f64a8a1940f5b2d367c1db6e.jpg?s=120&d=mm&r=g)
I'm hoping this discussion will return to the drawing the line question. http://stackoverflow.com/questions/8108688/in-python-when-should-i-use-a-fun... Alan Isaac
![](https://secure.gravatar.com/avatar/ad13088a623822caf74e635a68a55eae.jpg?s=120&d=mm&r=g)
On Tue, Feb 26, 2013 at 12:33 PM, eat <e.antero.tammi@gmail.com> wrote:
partially a joke. I don't see any good and simple rule to restrict the number of methods. dot was added as a method a few numpy versions ago, because it is painful to write nested or sequential dot products. Alan was in favor of the dot method and of matrix algebra because it's much easier on new users who come from a background that has a dot product as "*" or similar operator. As Skipper, I think the number of methods is not really huge (especially not numerical operations) Josef
![](https://secure.gravatar.com/avatar/ad13088a623822caf74e635a68a55eae.jpg?s=120&d=mm&r=g)
On Tue, Feb 26, 2013 at 1:11 PM, <josef.pktd@gmail.com> wrote:
99 was just the first number that came to mind that sounded exaggerated enough. (I like methods and will use __abs__ from now on, but I won't argue much in any direction of changes.) Josef http://en.wikipedia.org/wiki/99_Luftballons
![](https://secure.gravatar.com/avatar/a5c6e0b8f64a8a1940f5b2d367c1db6e.jpg?s=120&d=mm&r=g)
On 2/26/2013 1:11 PM, josef.pktd@gmail.com wrote:
Alan was in favor of the dot method
I still really like this, and it probably violates any simple rule for drawing the line. Nevertheless it would be nice to have some principle(s) other than the squeaky wheel principle for thinking about such proposals. Cheers, Alan
![](https://secure.gravatar.com/avatar/f14373168edcc55c5f2598a40de55c0d.jpg?s=120&d=mm&r=g)
Hi, Le 23/02/2013 20:25, Nathaniel Smith a écrit :
If x is a complex array, I feel that x.abs() and x.angle() would be natural complements to x.real and x.imag. Of course, x.angle() only make much sense for complex arrays while x.abs() makes sense for any numerical array. best, Pierre
participants (14)
-
Alan G Isaac
-
Benjamin Root
-
Charles R Harris
-
eat
-
Frédéric Bastien
-
josef.pktd@gmail.com
-
Nathaniel Smith
-
Paul Anton Letnes
-
Pierre Haessig
-
Robert Kern
-
Sebastian Berg
-
Skipper Seabold
-
Till Stensitzki
-
Todd