[Numpy-discussion] improving arraysetops
Wed Jun 17 08:06:39 CDT 2009
Neil Crighton wrote:
>>> What about merging unique and unique1d? They're essentially identical for an
>>> array input, but unique uses the builtin set() for non-array inputs and so is
>>> around 2x faster in this case - see below. Is it worth accepting a speed
>>> regression for unique to get rid of the function duplication? (Or can they be
>> unique1d can return the indices - can this be achieved by using set(), too?
> No, set() can't return the indices as far as I know.
>> The implementation for arrays is the same already, IMHO, so I would
>> prefer adding return_index, return_inverse to unique (automatically
>> converting input to array, if necessary), and deprecate unique1d.
>> We can view it also as adding the set() approach to unique1d, when the
>> return_index, return_inverse arguments are not set, and renaming
>> unique1d -> unique.
> This sounds good. If you don't have time to do it, I don't mind having
> a go at writing
> a patch to implement these changes (deprecate the existing unique1d, rename
> unique1d to unique and add the set approach from the old unique, and the other
> changes mentioned in http://projects.scipy.org/numpy/ticket/1133).
That would be really great - I will not be online starting tomorrow till
the end of next week (more or less), so I can really look at the issue
after I return.
>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xb5' in
>> position 28: ordinal not in range(128)
>> It disappears after increasing the array size, or the integer size.
>> In : np.__version__
>> Out: '1.4.0.dev7047'
> Weird! From the error message, it looks like a problem with ipython's timeit
> function rather than unique. I can't reproduce it on my machine
> (numpy 1.4.0.dev, r7059; IPython 0.10.bzr.r1163 ).
True, I have ipython 0.9.1, that might cause the problem.
More information about the Numpy-discussion