Menu
▾
▴
numpy-discussion
|
From: Simon B. <si...@ar...> - 2006-05-16 03:41:13
|
Sometime between 0.9.5 and 0.9.7.2502 the behaviour of nonzero changed: >>> a=numpy.array([1,1,0,1,1]) >>> a.nonzero() array([0, 1, 3, 4]) >>> now it returns a tuple: >>> a=numpy.array((0,1,1,0,0)) >>> a.nonzero() (array([1, 2]),) This is rather unpleasant for me. For example, my collegue uses OSX and finds only numpy 0.9.5 under darwinports. :( Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com |
|
From: Travis O. <oli...@ie...> - 2006-05-16 04:14:31
|
Simon Burton wrote: > Sometime between 0.9.5 and 0.9.7.2502 the behaviour of nonzero changed: > > >>>> a=numpy.array([1,1,0,1,1]) >>>> a.nonzero() >>>> > array([0, 1, 3, 4]) > > > now it returns a tuple: > > >>>> a=numpy.array((0,1,1,0,0)) >>>> a.nonzero() >>>> > (array([1, 2]),) > > This is rather unpleasant for me. For example, my collegue > uses OSX and finds only numpy 0.9.5 under darwinports. > > Chris Fonnesback releases quite up-to-date binary releases of NumPy and SciPy for Mac OSX. An alternative solution is to use the functional form: nonzero(a) works the same as a.nonzero() did before for backwards compatibility. The behavior of a.nonzero() was changed for compatibility with numarray. -Travis |
|
From: Simon B. <si...@ar...> - 2006-05-16 05:36:49
|
On Mon, 15 May 2006 22:13:57 -0600 Travis Oliphant <oli...@ie...> wrote: > > Chris Fonnesback releases quite up-to-date binary releases of NumPy and > SciPy for Mac OSX. Yes: http://homepage.mac.com/fonnesbeck/mac/index.html > > An alternative solution is to use the functional form: > > nonzero(a) works the same as a.nonzero() did before for backwards > compatibility. > > The behavior of a.nonzero() was changed for compatibility with numarray. Is this a general strategy employed by numpy ? Ie. functions have old semantics, methods have numarray semantics ? Scary. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com |
|
From: Alan G I. <ai...@am...> - 2006-05-16 19:08:20
|
1. I hope for an array 'a' that nonzero(a) and a.nonzero() will produce the same result, whatever convention is chosen. For 1d arrays only the numarray behavior can be consistent with nd arrays (which Numeric's 'nonzero' did not handle). But ... 2. How are people using this? I trust that the numarray behavior was well considered, but I would have expected coordinates to be grouped rather than spread across the arrays in the tuple. Thank you for any insight, Alan Isaac |
|
From: Simon B. <si...@ar...> - 2006-05-17 01:17:47
|
On Tue, 16 May 2006 15:15:23 -0400 Alan G Isaac <ai...@am...> wrote: > 2. How are people using this? I trust that the numarray > behavior was well considered, but I would have expected > coordinates to be grouped rather than spread across > the arrays in the tuple. Yes, this strikes me as bizarre. How about we make a new function, eg. argwhere, that returns an array of indices ? argwhere( array( [[0,1],[0,1]] ) ) -> [[0,1],[1,1]] Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com |
|
From: Francesc A. <fa...@ca...> - 2006-05-17 08:37:36
|
A Dimecres 17 Maig 2006 03:17, Simon Burton va escriure: > On Tue, 16 May 2006 15:15:23 -0400 > > Alan G Isaac <ai...@am...> wrote: > > 2. How are people using this? I trust that the numarray > > behavior was well considered, but I would have expected > > coordinates to be grouped rather than spread across > > the arrays in the tuple. > > Yes, this strikes me as bizarre. > How about we make a new function, eg. argwhere, that > returns an array of indices ? > > argwhere( array( [[0,1],[0,1]] ) ) -> [[0,1],[1,1]] +1 That could be quite useful. =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: Travis O. <oli...@ie...> - 2006-05-17 22:19:17
|
Simon Burton wrote: > On Tue, 16 May 2006 15:15:23 -0400 > Alan G Isaac <ai...@am...> wrote: > > >> 2. How are people using this? I trust that the numarray >> behavior was well considered, but I would have expected >> coordinates to be grouped rather than spread across >> the arrays in the tuple. >> > > The split-tuple is for fancy-indexing. That's how you index a multidimensional array using an array of integers. The output of a.nonzero() is setup to do that so that a[a.nonzero()] works. > Yes, this strikes me as bizarre. > How about we make a new function, eg. argwhere, that > returns an array of indices ? > > argwhere( array( [[0,1],[0,1]] ) ) -> [[0,1],[1,1]] > > I could see the value of this kind of function too. -Travis |
|
From: Alan G I. <ai...@am...> - 2006-05-17 21:33:50
|
On Tue, 16 May 2006, Alan G Isaac apparently wrote: > 2. How are people using this? I trust that the numarray > behavior was well considered, but I would have expected > coordinates to be grouped rather than spread across the > arrays in the tuple. OK, just to satisfy my curiosity: does the silence mean that nobody is using 'nonzero' in a fashion that leads them to prefer the current behavior to the "obvious" alternative of grouping the coordinates? Is the current behavior just an inherited convention, or is it useful in specific applications? Sorry to ask again, but I'm interested to know the application that is facilitated by getting one coordinate at a time, or possibly by getting e.g. an array of first coordinates without the others. Thank you, Alan Isaac |
|
From: Ed S. <sch...@ft...> - 2006-05-18 08:55:21
|
Alan G Isaac wrote:
> On Tue, 16 May 2006, Alan G Isaac apparently wrote:
>
>> 2. How are people using this? I trust that the numarray
>> behavior was well considered, but I would have expected
>> coordinates to be grouped rather than spread across the
>> arrays in the tuple.
>>
>
> OK, just to satisfy my curiosity:
> does the silence mean that nobody is using
> 'nonzero' in a fashion that leads them to
> prefer the current behavior to the "obvious"
> alternative of grouping the coordinates?
> Is the current behavior just an inherited
> convention, or is it useful in specific applications?
>
I also think a function that groups coordinates would be useful. Here's
a prototype:
def argnonzero(a):
return transpose(a.nonzero())
This has the same effect as:
def argnonzero(a):
nz = a.nonzero()
return array([[nz[i][j] for i in xrange(a.ndim)] for j in
xrange(len(nz[0]))])
The output is always a 2d array, so
>>> a
array([[ 0, 1, 2, 3],
[ 4, 0, 6, 7],
[ 8, 9, 0, 11]])
>>> argnonzero(a)
array([[0, 1],
[0, 2],
[0, 3],
[1, 0],
[1, 2],
[1, 3],
[2, 0],
[2, 1],
[2, 3]])
>>> b = a[0]
>>> argnonzero(b)
array([[1],
[2],
[3]])
>>> c = array([a, a-1, a-2])
>>> argnonzero(c)
array([[0, 0, 1],
[0, 0, 2],
...
It looks a little clumsy for 1d arrays, but I'd argue that, if NumPy
were to offer a function like this, it should always return a 2d array
whose rows are the coordinates for consistency, rather than returning
some squeezed version for indices into 1d arrays.
I'd support the addition of such a function to NumPy. Although it's
tiny, it's not obvious, and it might be useful.
-- Ed
|
|
From: Bill B. <wb...@gm...> - 2006-05-18 09:36:14
|
Aren't there quite a few functions that return indices like nonzero() does? Should they all have arg*** versions that just transpose the output of the non arg*** version? Maybe the answer is yes, but to me if all it takes to get what you needs is transpose() then I'm not sure how that fails to be obvious. You have [[x y z] [p d q]] and you want ([x p][y d][z q]). Looks like a job for transpose! Maybe a note in the docstring pointing out "the obvious" is what is really warranted. As in "hey, look, you can transpose the output of this function if you'd like the indices the other way, but the way it is it's more useful for indexing, as in a[a.nonzero()]." Sure would be nice if all you had to type was a.nonzero().T, though... ;-P --bill On 5/18/06, Ed Schofield <sch...@ft...> wrote: > > Alan G Isaac wrote: > > On Tue, 16 May 2006, Alan G Isaac apparently wrote: > > > >> 2. How are people using this? I trust that the numarray > >> behavior was well considered, but I would have expected > >> coordinates to be grouped rather than spread across the > >> arrays in the tuple. > >> > > > > OK, just to satisfy my curiosity: > > does the silence mean that nobody is using > > 'nonzero' in a fashion that leads them to > > prefer the current behavior to the "obvious" > > alternative of grouping the coordinates? > > Is the current behavior just an inherited > > convention, or is it useful in specific applications? > > > > I also think a function that groups coordinates would be useful. Here's > a prototype: > > def argnonzero(a): > return transpose(a.nonzero()) > > This has the same effect as: > > def argnonzero(a): > nz =3D a.nonzero() > return array([[nz[i][j] for i in xrange(a.ndim)] for j in > xrange(len(nz[0]))]) > > The output is always a 2d array, so > > >>> a > array([[ 0, 1, 2, 3], > [ 4, 0, 6, 7], > [ 8, 9, 0, 11]]) > > >>> argnonzero(a) > array([[0, 1], > [0, 2], > [0, 3], > [1, 0], > [1, 2], > [1, 3], > [2, 0], > [2, 1], > [2, 3]]) > > >>> b =3D a[0] > >>> argnonzero(b) > array([[1], > [2], > [3]]) > > >>> c =3D array([a, a-1, a-2]) > >>> argnonzero(c) > array([[0, 0, 1], > [0, 0, 2], > ... > > It looks a little clumsy for 1d arrays, but I'd argue that, if NumPy > were to offer a function like this, it should always return a 2d array > whose rows are the coordinates for consistency, rather than returning > some squeezed version for indices into 1d arrays. > > I'd support the addition of such a function to NumPy. Although it's > tiny, it's not obvious, and it might be useful. > > -- Ed > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > --=20 William V. Baxter III OLM Digital Kono Dens Building Rm 302 1-8-8 Wakabayashi Setagaya-ku Tokyo, Japan 154-0023 +81 (3) 3422-3380 |
|
From: Ed S. <sch...@ft...> - 2006-05-18 10:39:09
|
Bill Baxter wrote: > Aren't there quite a few functions that return indices like nonzero() > does? > Should they all have arg*** versions that just transpose the output of > the non arg*** version? > > Maybe the answer is yes, but to me if all it takes to get what you > needs is transpose() then I'm not sure how that fails to be obvious. > You have [[x y z] [p d q]] and you want ([x p][y d][z q]). Looks like > a job for transpose! > Maybe a note in the docstring pointing out "the obvious" is what is > really warranted. As in "hey, look, you can transpose the output of > this function if you'd like the indices the other way, but the way it > is it's more useful for indexing, as in a[ a.nonzero()]." Well, it wasn't immediately obvious to me how it could be done so elegantly. But I agree that a new function isn't necessary. I've re-written the docstring for the nonzero method in SVN to point out how to do it. > Sure would be nice if all you had to type was a.nonzero().T, though... ;-P No, this wouldn't be possible -- the output of the nonzero method is a tuple, not an array. Perhaps this is why it's not _that_ obvious ;) -- Ed |
|
From: Bill B. <wb...@gm...> - 2006-05-18 11:44:56
|
On 5/18/06, Ed Schofield <sch...@ft...> wrote: > > Bill Baxter wrote: > > Sure would be nice if all you had to type was a.nonzero().T, though... > ;-P > > No, this wouldn't be possible -- the output of the nonzero method is a > tuple, not an array. Perhaps this is why it's not _that_ obvious ;) Oh, I see. I did miss that bit. I think I may have even done something recently myself like vstack(where(a > val)).transpose() not realizing that plain old transpose() would work in place of vstack(xxx).transpose(). If you feel like copy-pasting your doc addition for nonzero() over to where() also, that would be nice. What other functions work like that? ... <me rummages around a little> ..= . actually it looks like most other functions similar to nonzero() return a boolean array, then you use where() if you need an index list. isnan(), iscomplex(), isinf(), isreal(), isneginf(), etc and of course all the boolean operators like a>0. So nonzero() is kind of an oddball. Is it actually any different from where(a!=3D0)? --bill |
|
From: Ed S. <sch...@ft...> - 2006-05-18 17:16:44
|
Bill Baxter wrote: > On 5/18/06, *Ed Schofield* <sch...@ft... > <mailto:sch...@ft...>> wrote: > > Bill Baxter wrote: > > Sure would be nice if all you had to type was a.nonzero().T, > though... ;-P > > No, this wouldn't be possible -- the output of the nonzero method is a > tuple, not an array. Perhaps this is why it's not _that_ obvious ;) > > > Oh, I see. I did miss that bit. I think I may have even done > something recently myself like > vstack(where(a > val)).transpose() > not realizing that plain old transpose() would work in place of > vstack(xxx).transpose(). > > If you feel like copy-pasting your doc addition for nonzero() over to > where() also, that would be nice. Okay, done. > What other functions work like that? ... <me rummages around a > little> ... actually it looks like most other functions similar to > nonzero() return a boolean array, then you use where() if you need an > index list. isnan(), iscomplex(), isinf(), isreal(), isneginf(), etc > and of course all the boolean operators like a>0. So nonzero() is > kind of an oddball. Is it actually any different from where(a!=0)? I think it's equivalent, only slightly more efficient... -- Ed |
|
From: George N. <gn...@go...> - 2006-05-18 12:16:59
|
This is a very useful thread. Made me think about what the present
arrangement is supposed to do.
My usage of this is to get out indices corresponding to a given condition.
So
E.g.
In [38]: a = arange(12).reshape(3,2,2)
Out[39]:
array([[[ 0, 1],
[ 2, 3]],
[[ 4, 5],
[ 6, 7]],
[[ 8, 9],
[10, 11]]])
In [40]: xx = where(a%2==0)
In [41]: xx
Out[41]:
(array([0, 0, 1, 1, 2, 2]),
array([0, 1, 0, 1, 0, 1]),
array([0, 0, 0, 0, 0, 0]))
The transpose idea should have been obvious to me...
In [48]: for i,j,k in transpose(xx):
....: print i,j,k
....:
....:
0 0 0
0 1 0
1 0 0
1 1 0
2 0 0
2 1 0
A 1D array
In [57]: aa = a.ravel()
In [49]: xx = where(aa%2==0)
In [53]: xx
Out[53]: (array([ 0, 2, 4, 6, 8, 10]),)
needs tuple unpacking:
n [52]: for i, in transpose(xx):
....: print i
....:
....:
0
2
4
6
8
10
Or more simply, the ugly
In [58]: for i in xx[0]:
....: print i
....:
....:
0
2
4
6
8
10
Alternatively, instead of transpose, we can simply use zip.
E.g. (3D)
In [42]: for i,j,k in zip(*xx):
....: print i,j,k
or (1D, again still needs unpacking)
In [56]: for i, in zip(*xx):
....: print i
|
|
From: Ed S. <sch...@ft...> - 2006-05-18 17:20:50
|
George Nurser wrote: > This is a very useful thread. Made me think about what the present > arrangement is supposed to do. Great! > Alternatively, instead of transpose, we can simply use zip. > > E.g. (3D) > In [42]: for i,j,k in zip(*xx): > ....: print i,j,k That's interesting. I've never thought of zip as a transpose operation before, but I guess it is ... -- Ed |
|
From: Alan G I. <ai...@am...> - 2006-05-18 17:55:17
|
On Thu, 18 May 2006, Ed Schofield apparently wrote: > I've never thought of zip as a transpose operation > before, but I guess it is http://mail.python.org/pipermail/python-list/2004-December/257416.html But I like it. Cheers, Alan Isaac |
|
From: Alan G I. <ai...@am...> - 2006-05-18 14:42:14
|
> Alan G Isaac wrote: >> 1. I hope for an array 'a' that nonzero(a) and a.nonzero() >> will produce the same result, whatever convention is >> chosen. On Wed, 17 May 2006, Travis Oliphant apparently wrote: > Unfortunately this won't work because the nonzero(a) behavior was > inherited from Numeric but the .nonzero() from numarray. > This is the price of trying to merge two user groups. The little bit > of pain is worth it, I think. One last comment: This is definitely trading off surprises for future users against ease for incoming Numeric users. So ... might the best to be to make numpy consistent but, assuming the more consistent numarray behavior is chosen, provide the Numeric behavior as part of the compatability module? fwiw, Alan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X