Re: [Numpy-discussion] [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
On Sun, Oct 14, 2012 at 8:24 PM, Zachary Pincus zachary.pin...@yale.eduwrote: It would be useful for the author of the PR to post a detailed comparison of this functionality with scipy.ndimage.generic_filter, which appears to have very similar functionality. I'll be durned. I created neighbor because I didn't find what I wanted, and to find now that I just didn't look in the right place is well ... Let's just say that I went for a long run last night. Searching for ndimage, I found that is has been around a long, long time. First in numarray, then moved to scipy. Really I could only nitpick about minor differences - kinda like a primary political campaign. On the face of it though, generic_filter looks better. First off it is written in C so likely will be faster and more efficient memory use. I didn't look at optimizing neighbor at all and at least my part of it is pure Python. Of course for all of the small differences, I like my choices better. :-) I would like to make a mild suggestion. Emphasis on mild. Maybe ndimage, in all or in part, should be brought into (back into?) Numpy and renamed. About the PR. Given that the neighbor functionality exists already, I will close the PR later today. Move along, nothing to see here... Side note: I wrote arraypad with the future idea that it would become easyish to include that functionality in other places, for example in neighbor. A Don't Repeat Yourself idea. Previously I had only seen Fortran pad capabilities in some of the Fast Fourier Transform functions. The generic_filter function includes several padding functions - written in C. This means that if arraypad needs be more efficient we have C code to base a better arraypad. Another side node: The measurements functions in ndimage are called zonal functions in the GIS field. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
Hi Tim, It's tricky to find functionality sometimes because as you've seen numpy and especially scipy are spread over very diverse domains with very diverse terminology! Usually someone on one or the other of the lists can help folks find some functionality, if not by name than by description... In any case, though, I hope you'll keep your code around and accessible to people in standalone form. Despite being a bit slower than the ndimage stuff, it seems like you've got a better set of boundary conditions, and some other niceties that may appeal to others too. Zach On Sun, Oct 14, 2012 at 8:24 PM, Zachary Pincus zachary.pin...@yale.edu wrote: It would be useful for the author of the PR to post a detailed comparison of this functionality with scipy.ndimage.generic_filter, which appears to have very similar functionality. I'll be durned. I created neighbor because I didn't find what I wanted, and to find now that I just didn't look in the right place is well ... Let's just say that I went for a long run last night. Searching for ndimage, I found that is has been around a long, long time. First in numarray, then moved to scipy. Really I could only nitpick about minor differences - kinda like a primary political campaign. On the face of it though, generic_filter looks better. First off it is written in C so likely will be faster and more efficient memory use. I didn't look at optimizing neighbor at all and at least my part of it is pure Python. Of course for all of the small differences, I like my choices better. :-) I would like to make a mild suggestion. Emphasis on mild. Maybe ndimage, in all or in part, should be brought into (back into?) Numpy and renamed. About the PR. Given that the neighbor functionality exists already, I will close the PR later today. Move along, nothing to see here... Side note: I wrote arraypad with the future idea that it would become easyish to include that functionality in other places, for example in neighbor. A Don't Repeat Yourself idea. Previously I had only seen Fortran pad capabilities in some of the Fast Fourier Transform functions. The generic_filter function includes several padding functions - written in C. This means that if arraypad needs be more efficient we have C code to base a better arraypad. Another side node: The measurements functions in ndimage are called zonal functions in the GIS field. Kindest regards, Tim ___ 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] [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
On 10.10.2012 15:42, Nathaniel Smith wrote: This PR submitted a few months ago adds a substantial new API to numpy, so it'd be great to get more review. No-one's replied yet, though... Any thoughts, anyone? Is it useful, could it be better...? Fast neighbor search is what scipy.spatial.cKDTree is designed for. There is an brand new version in SciPy master. It's not neighbor *search*, it's applying a function over an (arbitrary chosen and weighted) moving neighborhood in an nd array. It would be useful for the author of the PR to post a detailed comparison of this functionality with scipy.ndimage.generic_filter, which appears to have very similar functionality. Zach ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
Sorry, I'm away from the lab and did not have a chance to test is yet. I will do next week. Nicolas On Oct 11, 2012, at 15:48 , Nathaniel Smith wrote: On Thu, Oct 11, 2012 at 10:50 AM, Nicolas Rougier nicolas.roug...@inria.fr wrote: I missed the original post but I personally find this addition especially useful for my work in computational neuroscience. I did something vaguely similar in a small framework (http://dana.loria.fr/, you can look more specifically at http://dana.loria.fr/doc/connection.html for details). Examples are available from: http://dana.loria.fr/examples.html The actual computation can be made in several ways depending on the properties of the kernel but the idea is to compute an array K such that given an array A and a kernel k, A*K holds the expected result. This also work with sparse array for example when the kernel is very small. I suspect the PR will be quite efficient compared to what I did. Would the current PR be useful to you if merged as-is? A common pitfall with these sorts of contributions is that we realize only after merging it that there is some tiny detail of the API that makes it not-quite-usable for some people with related problems, so it'd be awesome if you could take a closer look. -n ___ 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] [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
I missed the original post but I personally find this addition especially useful for my work in computational neuroscience. I did something vaguely similar in a small framework (http://dana.loria.fr/, you can look more specifically at http://dana.loria.fr/doc/connection.html for details). Examples are available from: http://dana.loria.fr/examples.html The actual computation can be made in several ways depending on the properties of the kernel but the idea is to compute an array K such that given an array A and a kernel k, A*K holds the expected result. This also work with sparse array for example when the kernel is very small. I suspect the PR will be quite efficient compared to what I did. Nicolas On Oct 10, 2012, at 18:55 , Cera, Tim wrote: On Wed, Oct 10, 2012 at 1:58 AM, Travis E. Oliphant notificati...@github.com wrote: I'm not sure what to make of no comments on this PR. This seems like a useful addition. @timcera are you still interested in having this PR merged? Yes. I mentioned in PR comments that the lack of discussion is because my code engenders speechless awe in anyone who looks at it. :-) Of course speechless awe can come from two different reasons! Hopefully it is because my code is so awesome. Seriously, I really wanted some input, especially after I found #31. On Wed, Oct 10, 2012 at 7:24 AM, Eric Moore notificati...@github.com wrote: This seems to be trying to solve a very similar problem to #31 Internally I implemented something like rolling window, but I don't return the windows. Instead the contents of the windows are used for calculation of each windows 'central' cell in the results array. After seeing the rolling window function I thought it might be nice to bring that out into a callable function, so that similar functionality would be available. That particular function isn't useful to me directly, but perhaps others? Kindest regards, Tim ___ 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] [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
On Thu, Oct 11, 2012 at 10:50 AM, Nicolas Rougier nicolas.roug...@inria.fr wrote: I missed the original post but I personally find this addition especially useful for my work in computational neuroscience. I did something vaguely similar in a small framework (http://dana.loria.fr/, you can look more specifically at http://dana.loria.fr/doc/connection.html for details). Examples are available from: http://dana.loria.fr/examples.html The actual computation can be made in several ways depending on the properties of the kernel but the idea is to compute an array K such that given an array A and a kernel k, A*K holds the expected result. This also work with sparse array for example when the kernel is very small. I suspect the PR will be quite efficient compared to what I did. Would the current PR be useful to you if merged as-is? A common pitfall with these sorts of contributions is that we realize only after merging it that there is some tiny detail of the API that makes it not-quite-usable for some people with related problems, so it'd be awesome if you could take a closer look. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
