George Sakkis wrote:
> 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.
>
I'll add a little cautionary note as well: it won't work correctly if
there are no elements of a that equal value (in which case the max of
a==values is 0 and you'll just get the first values). It would be easy
enough to make this bullet proof:
def index(a, value):
arg = argmax(a == value)
if a[arg] != value:
raise IndexError("or whatever")
return arg
Unfortunately, that's no longer two lines and I wouldn't have been able
to use that Tim Peter's quote which needs to be thrown out from time to
time just on general principles.
>
>> [snip]
>> 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.
>
I agree with that for the most part.
>
>> 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.
>
Well, if you were to try to convince me like that, I would try to
convince you of your errant ways.by noting that numpy arrays are quite
dissimilar from lists in so many ways, that making them closer would
just lead to confusion as people asked for more and more list-like
behaviors (append, in, etc etc.). Lists and arrays aren't close enough
that conflating them could be made to work in any halfway sensible manner.
Lists and arrays are both examples of python sequences and they both
fully implement the sequence interface (and the iterarable interface for
that matter) but that's really the extent of their similarity.
Now whether an object based on array that implemented list semantics but
kept a numpy arrays memory frugality would be useful I cannot say.
However, that seems to be the kind of thing that should be a separate
type of object, perhaps reusing much of the array code, but having a
completely different interface. It also seems the kind of thing that
would likely have fairly limited use in practice, so if someone really
wants it I'd like to see it exist as a separate package for some period
of time to verify that it actually has a user base before it got
incorporated into numpy.
Not that I control these things.
> 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 *".
>
Oh yeah, you should almost never use "from anything import *" IMO. 'N'
seems to be the favored abreviation these days although I've always used
'np' (this helped when I was transition from Numeric to numarray and
then back to numpy as I used 'na' for numarray and np for numpy).
-tim
-------------------------------------------------------------------------
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
