Would it be possible to enhance np.unique(.) with a keyword kind
Hi, Especially when the keyword return_index of np.unique(.) is specified to be True, would it in general also be reasonable to be able to specify the sorting algorithm of the underlying np.argsort(.)? The rationale is that (for at least some of my cases) higher level algorithms seems to be too over complicated unless I'm not able to request a stable sorting order from np.unique(.) (like np.unique(., return_index= True, kind= 'mergesort'). (FWIW, I apparently do have a working local hack for this kind of functionality, but without extensive testing of 'all' corner cases). Thanks, eat
On Mon, Dec 19, 2011 at 6:27 PM, eat <e.antero.tammi@gmail.com> wrote:
Hi,
Especially when the keyword return_index of np.unique(.) is specified to be True, would it in general also be reasonable to be able to specify the sorting algorithm of the underlying np.argsort(.)?
The rationale is that (for at least some of my cases) higher level algorithms seems to be too over complicated unless I'm not able to request a stable sorting order from np.unique(.) (like np.unique(., return_index= True, kind= 'mergesort').
(FWIW, I apparently do have a working local hack for this kind of functionality, but without extensive testing of 'all' corner cases).
Just to understand this: Is the return_index currently always the first occurrence or random? I haven't found a use for return_index yet (but use return_inverse a lot), but if we are guaranteed to get the first instance, then this could be very useful. Josef
Thanks, eat
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Tue, Dec 20, 2011 at 2:33 AM, <josef.pktd@gmail.com> wrote:
On Mon, Dec 19, 2011 at 6:27 PM, eat <e.antero.tammi@gmail.com> wrote:
Hi,
Especially when the keyword return_index of np.unique(.) is specified to be True, would it in general also be reasonable to be able to specify the sorting algorithm of the underlying np.argsort(.)?
The rationale is that (for at least some of my cases) higher level algorithms seems to be too over complicated unless I'm not able to request a stable sorting order from np.unique(.) (like np.unique(., return_index= True, kind= 'mergesort').
(FWIW, I apparently do have a working local hack for this kind of functionality, but without extensive testing of 'all' corner cases).
Just to understand this:
Is the return_index currently always the first occurrence or random?
No, for current implementation it's not always the first occurrence returned. AFAIK, the only stable algorithm to provide this is ' mergesort' and that's why I'll like to have a keyword 'kind' to propagate down to then internals.
I haven't found a use for return_index yet (but use return_inverse a lot), but if we are guaranteed to get the first instance, then this could be very useful.
I think that 'return_inverse' will suffer of the same nondeterministic behavior as well. Thanks, eat
Josef
Thanks, eat
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Dec 19, 2011 at 8:16 PM, eat <e.antero.tammi@gmail.com> wrote:
Hi,
On Tue, Dec 20, 2011 at 2:33 AM, <josef.pktd@gmail.com> wrote:
On Mon, Dec 19, 2011 at 6:27 PM, eat <e.antero.tammi@gmail.com> wrote:
Hi,
Especially when the keyword return_index of np.unique(.) is specified to be True, would it in general also be reasonable to be able to specify the sorting algorithm of the underlying np.argsort(.)?
The rationale is that (for at least some of my cases) higher level algorithms seems to be too over complicated unless I'm not able to request a stable sorting order from np.unique(.) (like np.unique(., return_index= True, kind= 'mergesort').
(FWIW, I apparently do have a working local hack for this kind of functionality, but without extensive testing of 'all' corner cases).
Just to understand this:
Is the return_index currently always the first occurrence or random?
No, for current implementation it's not always the first occurrence returned. AFAIK, the only stable algorithm to provide this is ' mergesort' and that's why I'll like to have a keyword 'kind' to propagate down to then internals.
Thanks, then I'm all in favor of mergesort.
I haven't found a use for return_index yet (but use return_inverse a lot), but if we are guaranteed to get the first instance, then this could be very useful.
I think that 'return_inverse' will suffer of the same nondeterministic behavior as well.
I don't think so, because there is a unique mapping from observations to unique items. Josef
Thanks, eat
Josef
Thanks, eat
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Tue, Dec 20, 2011 at 3:41 AM, <josef.pktd@gmail.com> wrote:
Hi,
On Tue, Dec 20, 2011 at 2:33 AM, <josef.pktd@gmail.com> wrote:
On Mon, Dec 19, 2011 at 6:27 PM, eat <e.antero.tammi@gmail.com> wrote:
Hi,
Especially when the keyword return_index of np.unique(.) is specified
to
be True, would it in general also be reasonable to be able to specify the sorting algorithm of the underlying np.argsort(.)?
The rationale is that (for at least some of my cases) higher level algorithms seems to be too over complicated unless I'm not able to request a stable sorting order from np.unique(.) (like np.unique(., return_index= True, kind= 'mergesort').
(FWIW, I apparently do have a working local hack for this kind of functionality, but without extensive testing of 'all' corner cases).
Just to understand this:
Is the return_index currently always the first occurrence or random?
No, for current implementation it's not always the first occurrence returned. AFAIK, the only stable algorithm to provide this is ' mergesort' and that's why I'll like to have a keyword 'kind' to propagate down to
On Mon, Dec 19, 2011 at 8:16 PM, eat <e.antero.tammi@gmail.com> wrote: then
internals.
Thanks, then I'm all in favor of mergesort.
I haven't found a use for return_index yet (but use return_inverse a lot), but if we are guaranteed to get the first instance, then this could be very useful.
I think that 'return_inverse' will suffer of the same nondeterministic behavior as well.
I don't think so, because there is a unique mapping from observations to unique items.
But (source code of 1.6.1) indicates that keywords 'return_inverse' are 'return_index' are related, indeed. Just my 2 cents eat
Josef
Thanks, eat
Josef
Thanks, eat
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
participants (2)
-
eat -
josef.pktd＠gmail.com