[Numpy-discussion] Would it be possible to enhance np.unique(.) with a keyword kind

2011-12-19 Thread eat
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Would it be possible to enhance np.unique(.) with a keyword kind

2011-12-19 Thread josef . pktd
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?

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

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Would it be possible to enhance np.unique(.) with a keyword kind

2011-12-19 Thread eat
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.


 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

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Would it be possible to enhance np.unique(.) with a keyword kind

2011-12-19 Thread josef . pktd
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.

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


Re: [Numpy-discussion] Would it be possible to enhance np.unique(.) with a keyword kind

2011-12-19 Thread eat
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