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