Adding .abs() method to the array object
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
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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
On Sat, Feb 23, 2013 at 12:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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?
IIRC, there was a long thread about adding 'abs' back around 1.0.3-1.1.0 with Travis against it ;) I don't feel strongly one way or the other. Chuck
On Sat, Feb 23, 2013 at 7:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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?
Or even abs(a). -- Robert Kern
On Sat, Feb 23, 2013 at 3:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Feb 23, 2013 at 7:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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?
Or even abs(a).
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
-- Robert Kern _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Feb 23, 2013 at 8:20 PM, <josef.pktd@gmail.com> wrote:
On Sat, Feb 23, 2013 at 3:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Feb 23, 2013 at 7:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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?
Or even abs(a).
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
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
On Sat, Feb 23, 2013 at 9:34 PM, Benjamin Root <ben.root@ou.edu> 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.
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
First, sorry that i didnt search for an old thread, but because i disagree with conclusion i would at least address my reason:
I don't like np.abs(arr).max() because I have to concentrate to much on the braces, especially if arr is a calculation
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
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
conclusion i would at least address my reason:
I don't like np.abs(arr).max() because I have to concentrate to much on the braces, especially if arr is a calculation
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".
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
On Mon, Feb 25, 2013 at 8:50 AM, Skipper Seabold <jsseabold@gmail.com>wrote:
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
conclusion i would at least address my reason:
I don't like np.abs(arr).max() because I have to concentrate to much on the braces, especially if arr is a calculation
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".
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.
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.
From a practical reading and typing point of view, left-to-right makes sense, to add a new function you don't need to go way back to the beginning of a line and you don't need to read right-to-left to see what is going on. However, the line eventually gets too long, line breaks are inconvenient, and you eventually forget what was at the beginning. I think short left-to-right sequences are very nice. OTOH, one call/line is a bit like left-to-right, only up-to-down, and there is no right margin, but you do save the output generated on the previous line.
Herstein's attempt to revolutionise old algebraic habits never caught on. But it was a bold attempt ;) Chuck
On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote:
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
conclusion i would at least address my reason:
I don't like np.abs(arr).max() because I have to concentrate to much on the braces, especially if arr is a calculation
This exactly, adding an abs into an old expression is always a
due to the parenthesis. The argument that np.abs() also works is
disagree with little annoyance 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".
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
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...
I find myself typing things like
arr.abs()
and
arr.unique()
quite often.
Skipper _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Feb 25, 2013 at 9:20 PM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote:
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
conclusion i would at least address my reason:
I don't like np.abs(arr).max() because I have to concentrate to much on the braces, especially if arr is a calculation
This exactly, adding an abs into an old expression is always a
due to the parenthesis. The argument that np.abs() also works is
disagree with little annoyance 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".
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
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...
(np.array([1, 2, 3], dtype=object)).max() 3 (np.array([1, 2, 3], dtype=object)).__abs__().max() 3 (np.array([1, 2, '3'], dtype=object)).__abs__() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for abs(): 'str'
map(abs, [1, 2, 3]) [1, 2, 3] map(abs, [1, 2, '3']) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for abs(): 'str'
I don't see a difference. (I don't expect to use max abs on anything else than numbers.) Josef
I find myself typing things like
arr.abs()
and
arr.unique()
quite often.
Skipper _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Feb 25, 2013 at 9:58 PM, <josef.pktd@gmail.com> wrote:
On Mon, Feb 25, 2013 at 9:20 PM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote:
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
conclusion i would at least address my reason:
I don't like np.abs(arr).max() because I have to concentrate to much on the braces, especially if arr is a calculation
This exactly, adding an abs into an old expression is always a
due to the parenthesis. The argument that np.abs() also works is
disagree with little annoyance 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".
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
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...
(np.array([1, 2, 3], dtype=object)).max() 3 (np.array([1, 2, 3], dtype=object)).__abs__().max() 3 (np.array([1, 2, '3'], dtype=object)).__abs__() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for abs(): 'str'
map(abs, [1, 2, 3]) [1, 2, 3] map(abs, [1, 2, '3']) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for abs(): 'str'
or maybe more useful
from decimal import Decimal d = [Decimal(str(k)) for k in np.linspace(-1, 1, 5)] map(abs, d) [Decimal('1.0'), Decimal('0.5'), Decimal('0.0'), Decimal('0.5'), Decimal('1.0')]
np.asarray(d).__abs__() array([1.0, 0.5, 0.0, 0.5, 1.0], dtype=object) np.asarray(d).__abs__()[0] Decimal('1.0')
Josef
I don't see a difference.
(I don't expect to use max abs on anything else than numbers.)
Josef
I find myself typing things like
arr.abs()
and
arr.unique()
quite often.
Skipper _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, 2013-02-25 at 22:04 -0500, josef.pktd@gmail.com wrote:
On Mon, Feb 25, 2013 at 9:58 PM, <josef.pktd@gmail.com> wrote:
On Mon, Feb 25, 2013 at 9:20 PM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
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
conclusion i would at least address my reason:
<snip> Two small things (not sure if it matters much). But first almost all of
On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote: 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...
(np.array([1, 2, 3], dtype=object)).max() 3 (np.array([1, 2, 3], dtype=object)).__abs__().max() 3 (np.array([1, 2, '3'], dtype=object)).__abs__() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for abs(): 'str'
map(abs, [1, 2, 3]) [1, 2, 3] map(abs, [1, 2, '3']) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for abs(): 'str'
or maybe more useful
from decimal import Decimal d = [Decimal(str(k)) for k in np.linspace(-1, 1, 5)] map(abs, d) [Decimal('1.0'), Decimal('0.5'), Decimal('0.0'), Decimal('0.5'), Decimal('1.0')]
np.asarray(d).__abs__() array([1.0, 0.5, 0.0, 0.5, 1.0], dtype=object) np.asarray(d).__abs__()[0] Decimal('1.0')
Josef
I don't see a difference.
(I don't expect to use max abs on anything else than numbers.)
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.
Josef
I find myself typing things like
arr.abs()
and
arr.unique()
quite often.
Skipper _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Feb 26, 2013 at 10:58 AM, Sebastian Berg <sebastian@sipsolutions.net
wrote:
On Mon, 2013-02-25 at 22:04 -0500, josef.pktd@gmail.com wrote:
On Mon, Feb 25, 2013 at 9:58 PM, <josef.pktd@gmail.com> wrote:
On Mon, Feb 25, 2013 at 9:20 PM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
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
conclusion i would at least address my reason:
<snip> Two small things (not sure if it matters much). But first almost all of
On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote: 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...
(np.array([1, 2, 3], dtype=object)).max() 3 (np.array([1, 2, 3], dtype=object)).__abs__().max() 3 (np.array([1, 2, '3'], dtype=object)).__abs__() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for abs(): 'str'
map(abs, [1, 2, 3]) [1, 2, 3] map(abs, [1, 2, '3']) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for abs(): 'str'
or maybe more useful
from decimal import Decimal d = [Decimal(str(k)) for k in np.linspace(-1, 1, 5)] map(abs, d) [Decimal('1.0'), Decimal('0.5'), Decimal('0.0'), Decimal('0.5'), Decimal('1.0')]
np.asarray(d).__abs__() array([1.0, 0.5, 0.0, 0.5, 1.0], dtype=object) np.asarray(d).__abs__()[0] Decimal('1.0')
Josef
I don't see a difference.
(I don't expect to use max abs on anything else than numbers.)
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.
But doesn't this also apply to many existing methods?
On Tue, 2013-02-26 at 11:16 +0100, Todd wrote:
On Tue, Feb 26, 2013 at 10:58 AM, Sebastian Berg <sebastian@sipsolutions.net> wrote: On Mon, 2013-02-25 at 22:04 -0500, josef.pktd@gmail.com wrote: > On Mon, Feb 25, 2013 at 9:58 PM, <josef.pktd@gmail.com> wrote: > > On Mon, Feb 25, 2013 at 9:20 PM, Sebastian Berg > > <sebastian@sipsolutions.net> wrote: > >> On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote: > >>> 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 > >>> > conclusion i would at least address my reason: > >>> >
<snip> > >> 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... > > > >>>> (np.array([1, 2, 3], dtype=object)).max() > > 3 > >>>> (np.array([1, 2, 3], dtype=object)).__abs__().max() > > 3 > >>>> (np.array([1, 2, '3'], dtype=object)).__abs__() > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > TypeError: bad operand type for abs(): 'str' > > > >>>> map(abs, [1, 2, 3]) > > [1, 2, 3] > >>>> map(abs, [1, 2, '3']) > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > TypeError: bad operand type for abs(): 'str' > > or maybe more useful > > >>> from decimal import Decimal > >>> d = [Decimal(str(k)) for k in np.linspace(-1, 1, 5)] > >>> map(abs, d) > [Decimal('1.0'), Decimal('0.5'), Decimal('0.0'), Decimal('0.5'), Decimal('1.0')] > > >>> np.asarray(d).__abs__() > array([1.0, 0.5, 0.0, 0.5, 1.0], dtype=object) > >>> np.asarray(d).__abs__()[0] > Decimal('1.0') > > Josef > > > > > I don't see a difference. > > > > (I don't expect to use max abs on anything else than numbers.) > >
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.
But doesn't this also apply to many existing methods?
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...).
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 24. feb. 2013, at 02:20, josef.pktd@gmail.com wrote:
On Sat, Feb 23, 2013 at 3:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Feb 23, 2013 at 7:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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?
Or even abs(a).
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
Very well put. I wholeheartedly agree. I'd be sort of happy with all functions becoming np.xxx() in numpy 2.0, for consistency. Paul
On Sat, Feb 23, 2013 at 1:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Feb 23, 2013 at 7:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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?
Or even abs(a).
Well, that just calls a method: In [1]: ones(3).__abs__() Out[1]: array([ 1., 1., 1.]) Which shows the advantage of methods, they provide universal function hooks. Chuck
On Mon, Feb 25, 2013 at 7:11 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sat, Feb 23, 2013 at 1:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Feb 23, 2013 at 7:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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?
Or even abs(a).
Well, that just calls a method:
In [1]: ones(3).__abs__() Out[1]: array([ 1., 1., 1.])
Which shows the advantage of methods, they provide universal function hooks.
Maybe we should start to advertise magic methods. I only recently discovered I can use divmod instead of the numpy functions:
divmod(np.array([1.4]), 1) (array([ 1.]), array([ 0.4])) np.array([1.4]).__divmod__(1) (array([ 1.]), array([ 0.4]))
Josef
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Feb 25, 2013 at 7:49 PM, <josef.pktd@gmail.com> wrote:
On Mon, Feb 25, 2013 at 7:11 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sat, Feb 23, 2013 at 1:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Feb 23, 2013 at 7:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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?
Or even abs(a).
Well, that just calls a method:
In [1]: ones(3).__abs__() Out[1]: array([ 1., 1., 1.])
Which shows the advantage of methods, they provide universal function hooks.
Maybe we should start to advertise magic methods. I only recently discovered I can use divmod instead of the numpy functions:
divmod(np.array([1.4]), 1) (array([ 1.]), array([ 0.4])) np.array([1.4]).__divmod__(1) (array([ 1.]), array([ 0.4]))
Thanks for the hint. my new favorite :)
(freq - nobs * probs).__abs__().max() 132.0
Josef
Josef
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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
On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac <alan.isaac@gmail.com> wrote:
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
Proposed line: Reduction methods only. Discuss... Ben Root
On Tue, Feb 26, 2013 at 9:39 AM, Benjamin Root <ben.root@ou.edu> wrote:
On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac <alan.isaac@gmail.com> wrote:
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
Proposed line:
Reduction methods only.
Discuss...
arr.dot ? the 99 most common functions for which chaining looks nice. Josef
Ben Root
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Huh, On Tue, Feb 26, 2013 at 5:03 PM, <josef.pktd@gmail.com> wrote:
On Tue, Feb 26, 2013 at 9:39 AM, Benjamin Root <ben.root@ou.edu> wrote:
On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac <alan.isaac@gmail.com>
wrote:
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
Proposed line:
Reduction methods only.
Discuss...
arr.dot ?
the 99 most common functions for which chaining looks nice.
Care to elaborate more for us less uninitiated? Regards, -eat
Josef
Ben Root
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Feb 26, 2013 at 12:33 PM, eat <e.antero.tammi@gmail.com> wrote:
Huh,
On Tue, Feb 26, 2013 at 5:03 PM, <josef.pktd@gmail.com> wrote:
On Tue, Feb 26, 2013 at 9:39 AM, Benjamin Root <ben.root@ou.edu> wrote:
On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac <alan.isaac@gmail.com> wrote:
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
Proposed line:
Reduction methods only.
Discuss...
arr.dot ?
the 99 most common functions for which chaining looks nice.
Care to elaborate more for us less uninitiated?
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
Regards, -eat
Josef
Ben Root
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Feb 26, 2013 at 1:11 PM, <josef.pktd@gmail.com> wrote:
On Tue, Feb 26, 2013 at 12:33 PM, eat <e.antero.tammi@gmail.com> wrote:
Huh,
On Tue, Feb 26, 2013 at 5:03 PM, <josef.pktd@gmail.com> wrote:
On Tue, Feb 26, 2013 at 9:39 AM, Benjamin Root <ben.root@ou.edu> wrote:
On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac <alan.isaac@gmail.com> wrote:
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
Proposed line:
Reduction methods only.
Discuss...
arr.dot ?
the 99 most common functions for which chaining looks nice.
Care to elaborate more for us less uninitiated?
partially a joke. I don't see any good and simple rule to restrict the number of methods.
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
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
Regards, -eat
Josef
Ben Root
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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
On Tue, Feb 26, 2013 at 12:11 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sat, Feb 23, 2013 at 1:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Feb 23, 2013 at 7:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki <mail.till@gmx.de> wrote:
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.
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?
Or even abs(a).
Well, that just calls a method:
In [1]: ones(3).__abs__() Out[1]: array([ 1., 1., 1.])
Which shows the advantage of methods, they provide universal function hooks.
I'm not sure what point you are trying to make. It does not appear to be relevant to adding an ndarray.abs() method. -- Robert Kern
Hi, Le 23/02/2013 20:25, Nathaniel Smith a écrit :
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? (Just another usecase where I see the x.abs() notation useful)
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