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.31.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).
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 _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
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.comwrote:
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 Algebrahttp://tinyurl.com/apoerwn, where he did function composition lefttoright instead of righttoleft.
From a practical reading and typing point of view, lefttoright 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 righttoleft 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 lefttoright sequences are very nice. OTOH, one call/line is a bit like lefttoright, only uptodown, 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, 20130225 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:
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
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 _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Mon, Feb 25, 2013 at 9:20 PM, Sebastian Berg sebastian@sipsolutions.net wrote:
On Mon, 20130225 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:
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
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 _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
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, 20130225 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:
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
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 _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Mon, 20130225 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, 20130225 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.
Josef
I find myself typing things like
arr.abs()
and
arr.unique()
quite often.
Skipper _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Tue, Feb 26, 2013 at 10:58 AM, Sebastian Berg <sebastian@sipsolutions.net
wrote:
On Mon, 20130225 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, 20130225 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?
On Tue, 20130226 at 11:16 +0100, Todd wrote:
On Tue, Feb 26, 2013 at 10:58 AM, Sebastian Berg sebastian@sipsolutions.net wrote: On Mon, 20130225 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, 20130225 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...).
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
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
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
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
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
I'm hoping this discussion will return to the drawing the line question. http://stackoverflow.com/questions/8108688/inpythonwhenshouldiuseafun...
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/inpythonwhenshouldiuseafun...
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/inpythonwhenshouldiuseafun...
Alan Isaac
Proposed line:
Reduction methods only.
Discuss...
arr.dot ?
the 99 most common functions for which chaining looks nice.
Josef
Ben Root
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
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/inpythonwhenshouldiuseafun...
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
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
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/inpythonwhenshouldiuseafun...
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
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
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/inpythonwhenshouldiuseafun...
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
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
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.
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