Tim Hochberg wrote: > George Sakkis wrote: > > def index(a, value): > > return N.where(a==value)[0][0] > > > Or > > def index(a, value): > return argmax(a == value)
That's a bit easier to write and a bit harder to grok; that's ok, I can live with it. > > This works but seems clunky and less efficient than necessary. If there > > isn't a better alternative, I would welcome a new index() > > function/method in the next numpy release. > > > > > > Without commenting on the desirability of this particular function, > people seem awfully eager to add functions and methods everywhere. These > aren't free you know. They cost in terms of maintenance and potential > bugs, and in terms of making the already large function set even harder > to wrap ones head around. That's partly an organizational problem but > partly an issue of sheer size, neither of which are helped by adding a > bunch more stuff. > > Not every two-line Python function has to come pre-written > --Tim Peters I think the organizational problem is more serious in Numpy's case; any package with about 200 functions (according to http://www.scipy.org/Numpy_Example_List) in an almost flat namespace would feel the maintainability problem build up. > In the case of this particular function, what are the use cases? Are > they common (not just with you but with other numpy users)? Are the uses > speed critical? Is it a good building block for other numeric > functions? I'm skeptical of the above implementation as it doesn't fit > well with other similar numpy functions (argmin and argmax for example) > and I personally don't see much in the way of compelling uses for this, > but feel free to try to convince me otherwise. > > -tim As I said, I would welcome the addition of this function and I would use it if it was there, but I'm not particularly fervent about it. If I were to convince you, I'd argue about how numpy arrays can be considered generalizations of (1-d) sequences in many ways and how convenient would it be for users whose code expects python lists to work as is (thanks to duck typing) with 1-d numpy arrays. Another (indirect) argument would be the addition of functions that implement set-theoretic operations, and certainly lists are far more common than sets. I have to agree though that the flat namespace at its current size makes me uneasy too; I typically use "import numpy as N" instead of "from numpy import *". George ------------------------------------------------------------------------- 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 Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
