why sort does not accept a key?
I'm wondering if `sort` intentially does not accept a `key` or if this is just a missing feature? (I suppose that if the `order` argument is specified it would have to accept a sequence of keys ...) Thanks, Alan Isaac
On Mon, Mar 24, 2014 at 11:32 AM, Alan G Isaac <alan.isaac@gmail.com> wrote:
I'm wondering if `sort` intentionally does not accept a `key` or if this is just a missing feature?
It would be very inefficient to call a key function on every element compared during the sort. See np.argsort and np.lexsort for faster alternatives.
On Mon, Mar 24, 2014 at 11:32 AM, Alan G Isaac wrote:
I'm wondering if `sort` intentionally does not accept a `key` or if this is just a missing feature?
On 3/24/2014 11:47 AM, Alexander Belopolsky wrote:
It would be very inefficient to call a key function on every element compared during the sort. See np.argsort and np.lexsort for faster alternatives.
But the keys could be as in `lexsort`. I am currently using `argsort`, but I can do so because I don't need a lexicographically determined sort order for the indexes. To close with a related question: what is the preferred idiom for a descending sort? Thanks, Alan
On Mon, Mar 24, 2014 at 12:08 PM, Alan G Isaac <alan.isaac@gmail.com> wrote:
On Mon, Mar 24, 2014 at 11:32 AM, Alan G Isaac wrote:
I'm wondering if `sort` intentionally does not accept a `key` or if this is just a missing feature?
On 3/24/2014 11:47 AM, Alexander Belopolsky wrote:
It would be very inefficient to call a key function on every element compared during the sort. See np.argsort and np.lexsort for faster alternatives.
But the keys could be as in `lexsort`.
I am currently using `argsort`, but I can do so because I don't need a lexicographically determined sort order for the indexes.
To close with a related question: what is the preferred idiom for a descending sort?
adding [::-1] just creates a new view, pretty low cost. Josef
Thanks, Alan
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Mar 24, 2014 at 12:08 PM, Alan G Isaac
what is the preferred idiom for a descending sort?
On 3/24/2014 12:13 PM, josef.pktd@gmail.com wrote:
adding [::-1] just creates a new view, pretty low cost.
I meant when you need to sort on a key (another vector). Currently I'm just reversing the result of argsort with [::-1] but this changes the sort order (relative to a stable descending sort). Alan Isaac
On Mon, Mar 24, 2014 at 11:05 AM, Alan G Isaac <alan.isaac@gmail.com> wrote:
On Mon, Mar 24, 2014 at 12:08 PM, Alan G Isaac
what is the preferred idiom for a descending sort?
On 3/24/2014 12:13 PM, josef.pktd@gmail.com wrote:
adding [::-1] just creates a new view, pretty low cost.
I meant when you need to sort on a key (another vector).
Currently I'm just reversing the result of argsort with [::-1] but this changes the sort order (relative to a stable descending sort).
For integer types you can use the complement as the key In [9]: ~arange(4, dtype=uint8) Out[9]: array([255, 254, 253, 252], dtype=uint8) In [10]: ~arange(4, dtype=int8) Out[10]: array([-1, -2, -3, -4], dtype=int8) For float types you would need to use the negative. Chuck
On Mon, Mar 24, 2014 at 11:57 AM, Alan G Isaac <alan.isaac@gmail.com> wrote:
On 3/24/2014 1:41 PM, Charles R Harris wrote:
For float types you would need to use the negative.
Yes, that's all I could come up with. So ... shd `sort` have a `reverse` option, like Python's builtin?
Well, it would double the number of sorts if we kept them efficient with efficient type specific compares. Alternatively, we could sort the reverse option using less efficient compare function calls. I think whether or not we add a reverse option should depend on how many want it. One potential problem would be that the sort function pointers are built into PyArray_ArrFuncs, and adding more might be problematic. That has been a continuing source of pain, for instance in adding the partition and binsearch functions, so it might be worth just expanding that structure. Chuck
participants (4)
-
Alan G Isaac -
Alexander Belopolsky -
Charles R Harris -
josef.pktd＠gmail.com