Re: [Numpy-discussion] finding index in an array...
josef.p...@gmail.com a écrit :
something like this should work to find rows with specific elements,
if I understand you correctly.
You did ;-)
np.nonzero(A.view([('',float)]*3) == np.array((1,2,3),[('',float)]*3))[0]
It creates an extra dimension, that needs to be removed with [0], but
it takes to long now, to remember how to get rid of it.
Ok, I get it.
Thanks.
BTW, I was thinking this was a FAQ and there was a more straightforward
answer, or a buitlin function to do the trick...
Cheers,
--
Fred
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] finding index in an array...
Hi Fred,
here is another solution
A = np.arange(99).reshape((33,3)
mask = (A==np.array([0,1,2]))
np.nonzero(np.prod(mask, axis=1))[0]
array([0]
I found it to be less elegant than Josef's solution changing the dtype of
the array, but it may be easier to understand if you're not very familiar
with dtypes. Also, it is a bit faster on my computer:
%timeit np.nonzero(A.view([('',int)]*3) ==
np.array((0,1,2),[('',int)]*3))[0]
1 loops, best of 3: 61.8 µs per loop
%timeit np.nonzero(np.prod((A==np.array([0,1,2])), axis=1))[0]
1 loops, best of 3: 38.1 µs per loop
Cheers,
Emmanuelle
On Sat, Jun 13, 2009 at 01:08:48AM +0200, fred wrote:
Hi,
Say I have an array A with shape (10,3) and
A[3,:] = [1,2,3]
I want to find the index of the array in which I have these values [1,2,3].
How can I do that?
The only workaround I have found is to use a list:
A.tolist().index([1,2, 3])
That works fine, but is there a better solution (without using list, for
instance)?
TIA.
Cheers,
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] finding index in an array...
Emmanuelle Gouillart a écrit : Hi Fred, Hi Manue ;-) here is another solution A = np.arange(99).reshape((33,3) mask = (A==np.array([0,1,2])) np.nonzero(np.prod(mask, axis=1))[0] array([0] I found it to be less elegant than Josef's solution changing the dtype of the array, but it may be easier to understand if you're not very familiar with dtypes. I have no problem. Also, it is a bit faster on my computer: I take it. Thanks! Cheers, -- Fred ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] finding index in an array...
On Sat, Jun 13, 2009 at 5:51 AM, fredfred...@gmail.com wrote: Emmanuelle Gouillart a écrit : Hi Fred, Hi Manue ;-) here is another solution A = np.arange(99).reshape((33,3) mask = (A==np.array([0,1,2])) np.nonzero(np.prod(mask, axis=1))[0] array([0] I found it to be less elegant than Josef's solution changing the dtype of the array, but it may be easier to understand if you're not very familiar with dtypes. I have no problem. I think using a view instead of broadcasting in this case is unnecessarily complicated. Maybe I was practicing views with structured types too much. using all instead of prod may be more descriptive: (A == np.array([1,2,3])).all(1).nonzero()[0] array([3, 7]) (A == [1,2,3]).all(1).nonzero()[0] array([3, 7]) Josef Also, it is a bit faster on my computer: I take it. Thanks! Cheers, -- Fred ___ 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
Re: [Numpy-discussion] Ready for review: PyArrayNeighIterObject, an iterator to iterate over a neighborhood in arbitrary arrays
On Sat, Jun 13, 2009 at 7:46 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Hi,
I have cleaned up a bit the code, and would like to suggest the
inclusion of a neighborhood iterator for numpy. Stéfan took a look at it
already, but it needs more eyeballs. It is a subclass of
PyArrayIterObject, and can be used to iterate over a neighborhood of a
point (handling boundaries with 0 padding for the time being).
http://codereview.appspot.com/75055/show
I have used it to replace the current for code correlateND in
scipy.signal, where it works quite well (I think it makes the code more
readable in that case).
Some nitpicks:
1) The name neigh sounds like a horse. Maybe region, neighborhood, or
something similar would be better.
2) Is PyObject_Init NULL safe?
ret = PyArray_malloc(sizeof(*ret));
+PyObject_Init((PyObject*)ret,PyArrayNeighIter_Type);
+if (ret == NULL) {
+return NULL;
+}
3) Documentation is needed. In particular, I think it worth mentioning that
the number of bounds is taken from the PyArrayIterObject, which isn't the
most transparent thing.
Otherwise, looks good.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Ready for review: PyArrayNeighIterObject, an iterator to iterate over a neighborhood in arbitrary arrays
On Sat, Jun 13, 2009 at 12:00 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, Jun 13, 2009 at 7:46 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Hi,
I have cleaned up a bit the code, and would like to suggest the
inclusion of a neighborhood iterator for numpy. Stéfan took a look at it
already, but it needs more eyeballs. It is a subclass of
PyArrayIterObject, and can be used to iterate over a neighborhood of a
point (handling boundaries with 0 padding for the time being).
http://codereview.appspot.com/75055/show
I have used it to replace the current for code correlateND in
scipy.signal, where it works quite well (I think it makes the code more
readable in that case).
Some nitpicks:
1) The name neigh sounds like a horse. Maybe region, neighborhood, or
something similar would be better.
2) Is PyObject_Init NULL safe?
ret = PyArray_malloc(sizeof(*ret));
+PyObject_Init((PyObject*)ret,PyArrayNeighIter_Type);
+if (ret == NULL) {
+return NULL;
+}
3) Documentation is needed. In particular, I think it worth mentioning that
the number of bounds is taken from the PyArrayIterObject, which isn't the
most transparent thing.
More nitpicks:
1) Since reference counting is such a pain, you should document that the
constructor returns a new reference and that the PyArrayIterObject does not
need to have its reference count incremented before the call and that the
reference count is unchanged on failure.
2) Why are _update_coord_iter(c) and _inc_set_ptr(c) macros? Why are they
defined inside functions? If left as macros, they should be in CAPS, but why
not just write them out?
3) Is it really worth the hassle to use inline functions? What does it buy
in terms of speed that justifies the complication?
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Ready for review: PyArrayNeighIterObject, an iterator to iterate over a neighborhood in arbitrary arrays
On Sun, Jun 14, 2009 at 3:22 AM, Charles R Harrischarlesr.har...@gmail.com wrote: 1) Since reference counting is such a pain, you should document that the constructor returns a new reference and that the PyArrayIterObject does not need to have its reference count incremented before the call and that the reference count is unchanged on failure. OK. 2) Why are _update_coord_iter(c) and _inc_set_ptr(c) macros? Why are they defined inside functions? If left as macros, they should be in CAPS, but why not just write them out? They are macro because they are reused in the 2d specialized functions (I will add 3d too) 3) Is it really worth the hassle to use inline functions? What does it buy in terms of speed that justifies the complication? Which complication are you talking about ? Except NPY_INLINE, I see none. In terms of speed, we are talking about several times faster. Think about using if for correlate, for example: you have a NxN image with a MxM kernel: PyArrayNeigh_IterNext will be called NxNxMxM times... I don't remember the numbers, but it was several times slower without the inline with gcc 4.3 on Linux. The 2d optimized functions, which just do manual loop unrolling, already buy up to a factor 2x. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Ready for review: PyArrayNeighIterObject, an iterator to iterate over a neighborhood in arbitrary arrays
On Sat, Jun 13, 2009 at 12:35 PM, David Cournapeau courn...@gmail.comwrote: On Sun, Jun 14, 2009 at 3:22 AM, Charles R Harrischarlesr.har...@gmail.com wrote: 1) Since reference counting is such a pain, you should document that the constructor returns a new reference and that the PyArrayIterObject does not need to have its reference count incremented before the call and that the reference count is unchanged on failure. OK. 2) Why are _update_coord_iter(c) and _inc_set_ptr(c) macros? Why are they defined inside functions? If left as macros, they should be in CAPS, but why not just write them out? They are macro because they are reused in the 2d specialized functions (I will add 3d too) IIRC, inline doesn't recurse, so there is some advantage to having these as macros. But I really dislike seeing macros defined inside of functions, especially when they aren't exclusive to that function. So at least move them outside. But often it is clearer for code maintainence to simply write them out, it just takes a few more lines. IOW, use macros judiciously. 3) Is it really worth the hassle to use inline functions? What does it buy in terms of speed that justifies the complication? Which complication are you talking about ? Except NPY_INLINE, I see none. In terms of speed, we are talking about several times faster. That's what I wanted to hear. But in c++ is generally best for simplicity and debugging to start out not using inlines, then add them is benchmarks show a decent advantage. And in those cases it is best if the inlines are just a few lines long. Think about using if for correlate, for example: you have a NxN image with a MxM kernel: PyArrayNeigh_IterNext will be called NxNxMxM times... I don't remember the numbers, but it was several times slower without the inline with gcc 4.3 on Linux. The 2d optimized functions, which just do manual loop unrolling, already buy up to a factor 2x. So what is the tradeoff between just unrolling the loops vs inline functions? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Ready for review: PyArrayNeighIterObject, an iterator to iterate over a neighborhood in arbitrary arrays
On Sat, Jun 13, 2009 at 12:29 PM, David Cournapeau courn...@gmail.comwrote: On Sun, Jun 14, 2009 at 3:00 AM, Charles R Harrischarlesr.har...@gmail.com wrote: On Sat, Jun 13, 2009 at 7:46 AM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: Hi, I have cleaned up a bit the code, and would like to suggest the inclusion of a neighborhood iterator for numpy. Stéfan took a look at it already, but it needs more eyeballs. It is a subclass of PyArrayIterObject, and can be used to iterate over a neighborhood of a point (handling boundaries with 0 padding for the time being). http://codereview.appspot.com/75055/show I have used it to replace the current for code correlateND in scipy.signal, where it works quite well (I think it makes the code more readable in that case). Some nitpicks: 1) The name neigh sounds like a horse. Maybe region, neighborhood, or something similar would be better. Neighborhood makes the name quite long - maybe region would be better, although region does not imply the notion of contiguity ? It does make it long, which is an inconvenience to the coder. But I think it is easier on the reader. Hmm... a thesaurus also suggests zone, area, and vicinity. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] More on doc-ing new functions
Are new functions automatically added to the Numpy Doc Wiki? In particular: 0) is the documentation itself (assuming there is some) added in such a way that it can be edited by Wiki users; and 1) is the name of the function automatically added to a best guess category in the Milestones? If not, if we can remember to do so, when adding a new function, please add an issue at http://code.google.com/p/numpydocmarathon09/issues to record that these chores need doing. Thanks! DG ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Indexing with integer ndarrays
Hi folks, This is probably a very simple question, but it has me stumped... I have an integer 2D array containing 3rd dimesion indicies that I'd like to use to index values in a 3D array. Basically, I want the equivalent of: output = np.zeros((ny,nx)) for i in xrange(ny): for j in xrange(nx): z = grid[i,j] output[j,i] = bigVolume[j,i,z] Where grid is my 2D array of indicies and bigVolume is my 3D array. I've read the numpy-user and numpybook sections on indexing with an integer ndarray, but I'm still not quite able to wrap my head around how it should work. I'm sure I'm missing something obvious (I haven't been using numpy particularly long). If it helps anyone visualize it, I'm essentially trying to extract attributes out of a seismic volume along the surface of a horizion. Thanks! -Joe ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Indexing with integer ndarrays
On Sat, Jun 13, 2009 at 19:11, Joe Kingtonjking...@wisc.edu wrote: Hi folks, This is probably a very simple question, but it has me stumped... I have an integer 2D array containing 3rd dimesion indicies that I'd like to use to index values in a 3D array. Basically, I want the equivalent of: output = np.zeros((ny,nx)) for i in xrange(ny): for j in xrange(nx): z = grid[i,j] output[j,i] = bigVolume[j,i,z] Where grid is my 2D array of indicies and bigVolume is my 3D array. I've read the numpy-user and numpybook sections on indexing with an integer ndarray, but I'm still not quite able to wrap my head around how it should work. I'm sure I'm missing something obvious (I haven't been using numpy particularly long). If it helps anyone visualize it, I'm essentially trying to extract attributes out of a seismic volume along the surface of a horizion. I discuss this particular use case (well, a little different; we are pulling out a thin slab around a horizon rather than a slice) here: http://mail.scipy.org/pipermail/numpy-discussion/2008-July/035776.html -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Indexing with integer ndarrays
Thank you! That answered things quite nicely. My apologies for not finding the earlier discussion before sending out the question... Thanks again, -Joe On Sat, Jun 13, 2009 at 7:17 PM, Robert Kern robert.k...@gmail.com wrote: On Sat, Jun 13, 2009 at 19:11, Joe Kingtonjking...@wisc.edu wrote: Hi folks, This is probably a very simple question, but it has me stumped... I have an integer 2D array containing 3rd dimesion indicies that I'd like to use to index values in a 3D array. Basically, I want the equivalent of: output = np.zeros((ny,nx)) for i in xrange(ny): for j in xrange(nx): z = grid[i,j] output[j,i] = bigVolume[j,i,z] Where grid is my 2D array of indicies and bigVolume is my 3D array. I've read the numpy-user and numpybook sections on indexing with an integer ndarray, but I'm still not quite able to wrap my head around how it should work. I'm sure I'm missing something obvious (I haven't been using numpy particularly long). If it helps anyone visualize it, I'm essentially trying to extract attributes out of a seismic volume along the surface of a horizion. I discuss this particular use case (well, a little different; we are pulling out a thin slab around a horizon rather than a slice) here: http://mail.scipy.org/pipermail/numpy-discussion/2008-July/035776.html -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ 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
Re: [Numpy-discussion] Elementary Array Switching
It seems to be working now--I think my problem is elsewhere. Sorry... ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
