From: Charles R H. <cha...@gm...> - 2006-09-19 18:42:28
|
On 9/19/06, Francesc Altet <fa...@ca...> wrote: > > A Dimarts 19 Setembre 2006 19:21, Charles R Harris va escriure: > > On 9/19/06, Francesc Altet <fa...@ca...> wrote: > > > A Dimarts 19 Setembre 2006 07:18, Charles R Harris va escriure: > > > > I note that argsort also produces indexes that are hard to use in > the > > > > ndim>1 case. > > > > > > Perhaps it is worth to mention here that I've always liked to have a > > > sort() > > > and argsort() functionality merged in one shot function (or method). > > > Having > > > both separated implies two sorts, while if I'd have such a combo > > > available, > > > the resulting operation would take quite less time. > > > > Do you want both the indexes and index sorted array returned, or just > sort > > the array using indexes, i.e., something like > > > > a.sort(kind="quicksort", method="indirect") > > Uh, I don't understand what do you mean by "sort the array using indexes", > sorry. > > What I'd like is to get the indexes and the sorted array returned. Or, > another > option could be getting the sorted indexes returned and a sort of the > array > done in-place (which is surely faster). Don't know about the faster part, it depends on the architecture and the size of the elements being swapped. It is the fact that the new quicksort does 1/2 as many swaps together with the type specific code that makes it faster than the original numpy version. The overhead in the current indirect sorts comes mostly from the indirect references to array elements in the innermost loop and it is quite possible that doing swaps on both the indexes and the array would be a bigger hit than the current argsort followed by a suitable take type function. Lexsort is another function that would benefit from what we are discussing. Chuck |