Hi, On Tue, Dec 20, 2011 at 3:41 AM, <josef.p...@gmail.com> wrote:
> On Mon, Dec 19, 2011 at 8:16 PM, eat <e.antero.ta...@gmail.com> wrote: > > Hi, > > > > On Tue, Dec 20, 2011 at 2:33 AM, <josef.p...@gmail.com> wrote: > >> > >> On Mon, Dec 19, 2011 at 6:27 PM, eat <e.antero.ta...@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. > 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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
