On 9/18/06, Charles R Harris <[EMAIL PROTECTED]> wrote:
I note that argsort also produces indexes that are hard to use in the ndim>1 case. The two problems aren't quite equivalent because argsort maintains ndim while argmax reduces ndim by one, but it would be nice if there was something that would work for both. Using imax[...,newaxis] would make the shapes compatible for input but then the output would need to lose the newaxis on return. Hmmm. These are both examples of an indirect indexing problem where the indices on the specified axis are a function of the indices on the other axis. Using the other indices in the argmax case yields a scalar index while in the argsort case it yields a 1d array that can be used for fancy indexing. I'm just floating around here trying to think of a consistent way to regard these things. Ummm, and I think this could work. In fact, the arrays could be even deeper and fancy indexing on the specified axis would produce what was essentially an array of arrays. This is sort of the photo-negative version of take.
Apropos the overloaded return types, I think that that is precisely what makes it tricky to use functions that may return either copies or views. The results should really be marked read only because otherwise unexpected results can arise.
Chuck
On 9/18/06, Bill Baxter < [EMAIL PROTECTED]> wrote:On 9/19/06, Charles R Harris <[EMAIL PROTECTED]> wrote:
> On 9/18/06, Bill Baxter < [EMAIL PROTECTED]> wrote:
> > I find myself often wanting both the max and the argmax of an array.
> > (And same for the other arg* functions)
> > You have to do something like
> > a = rand(10,5)
> > imax = a.argmax(axis=0)
> > vmax = a[(imax, range(5))]
> >
> I don't generally like overloading return values, the function starts to
> lose its definition and becomes a bit baroque where simply changing a
> keyword value can destroy the viability of the following code.
Agreed. Seems like the only justification is if you get multiple
results from one calculation but only rarely want the extra values.
It doesn't make sense to always return them, but it's also not worth
making a totally different function.
> But I can see the utility of what you want. Hmm, this problem is not unique to argmax.
> Maybe what we need is a general way to extract values, something like
>
> extract(a, imax, axis=0)
>
> to go along with all the single axis functions.
Yes, I think that would be easier to remember.
It should also work for the axis=None case.
imax = a.argmax(axis=None)
v = extract(a, imax, axis=None)
It shouldn't be too difficult to jig something up given all the example code. I can do that, but I would like more input first. The questions I have are these.
1) Should it be done?
2) Should it be a method? (functions being somewhat deprecated)
3) What name should it have?
I think Travis will have to weigh in on this. IIRC, he felt that the number of methods was getting out of hand.--Bill
Chuck
I note that argsort also produces indexes that are hard to use in the ndim>1 case. The two problems aren't quite equivalent because argsort maintains ndim while argmax reduces ndim by one, but it would be nice if there was something that would work for both. Using imax[...,newaxis] would make the shapes compatible for input but then the output would need to lose the newaxis on return. Hmmm. These are both examples of an indirect indexing problem where the indices on the specified axis are a function of the indices on the other axis. Using the other indices in the argmax case yields a scalar index while in the argsort case it yields a 1d array that can be used for fancy indexing. I'm just floating around here trying to think of a consistent way to regard these things. Ummm, and I think this could work. In fact, the arrays could be even deeper and fancy indexing on the specified axis would produce what was essentially an array of arrays. This is sort of the photo-negative version of take.
Apropos the overloaded return types, I think that that is precisely what makes it tricky to use functions that may return either copies or views. The results should really be marked read only because otherwise unexpected results can arise.
Chuck
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
