Equivalent to list.index ?

George Sakkis george.sakkis at gmail.com
Sun Nov 12 22:25:05 EST 2006


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




More information about the NumPy-Discussion mailing list