| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Tweak a few lines so that arrays with an axis with length 0
don't break the np.unique code.
Closes gh-15559.
|
|
|
|
|
| |
This code is from github user huonw, from this PR:
https://github.com/numpy/numpy/pull/15565
|
|
|
|
|
|
|
| |
Inheriting from object was necessary for Python 2 compatibility to use
new-style classes. In Python 3, this is unnecessary as there are no
old-style classes.
Dropping the object is more idiomatic Python.
|
|
|
|
|
| |
As numpy is Python 3 only, these import statements are now unnecessary
and don't alter runtime behavior.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c088383cb290ca064d456e89d79177a0e234cb8d and
uses the same kind casting rule for the additional keyword arguments
``to_end`` and ``to_begin``. This results in slightly more leniant
behaviour for integers (which can now have overflows that are
hidden), but fixes an issue with the handling of NaN.
Generally, this behaviour seems more conistent with what NumPy does
elsewhere. The Overflow issue exists similar in many other places
and should be solved by integer overflow warning machinery while
the actual cast takes place.
Closes gh-13103
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#12448)
* Review F401,F841,F842 flake8 errors (unused variables, imports)
* Review comments
* More tests in test_installed_npymath_ini
* Review comments
|
|
|
|
|
|
|
|
| |
* add unit test for setdiff1d covering code
path where assume_unique is True
* remove setdiff1d docstring guarantee that
returned value is sorted -- it is not
|
| |
|
|
|
|
|
|
|
|
|
| |
The function was failing for non-ndarray objects that defined
that defined __array__, in particular `xarray.DataArray`. Fix
by calling asanyarray on the inputs, which was done implicitly
before.
Closes #11772.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* added function commonpts1d
* Update arraysetops.py
* Update arraysetops.py
* modified intersect1d to return common indices
Proposed this idea in previous pull request (https://github.com/numpy/numpy/pull/10683) and made suggested changes for implementing this idea to have relevant common indices that correspond to the values in the intersection of the two arrays.
* update intersect1d with suggested changes
* implemented return_indices options for intersect1d
I've tested out the above code and for the ~10 different test sets I've tried it's worked thus far. It's probably not the cleanest implementation but it works and is vectorized.
* cleaned up structure for intersect1d
* fixed copy-paste error, added second test, changed a conditional
* Testing return_indices in intersect1d
* formatting
* created separate test function for intersect1d indices, added spaces after commas
* fixed up example and some style
* fixed style
* style change
* removed one example
* removed extra space
* added version number for return_indices
* added 'return_indices' keyword for np.intersect1d
* fixed formatting
* updated return_indices entry
* fixed some typos and style
* added bit about first instance of a value being used
* STY: Fix comment formats
* DOC: missing space
* DOC: correct parameter names in docstring
* made suggested changes
* fixed a mistake from previous update
also added documentation for comm1, comm2 to match doc from np.unique
* added in tests for 2d inputs
* STY: Add missing spaces around commas
* TST: Correct array to actually be unique
* STY: Spaces at beginning of comments
|
| |
|
|
|
|
|
| |
That function is nose specific and has not worked since `__init__` files
were added to the tests directories.
|
|
|
|
|
|
|
|
| |
The optimization was to sort integer subarrays by treating them as
strings of unsigned bytes. That worked fine for finding the unique
subarrays, but the sort order of the results could be unexpected.
Closes #10495.
|
| |
|
|
|
| |
[ci skip]
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #9137
|
|
|
|
|
|
| |
This fixes gh-8331
Also update the docs for arraysetops to remove the outdated "1D" from the
description, which was already incorrect for np.unique.
|
|
|
|
|
|
|
| |
Previously, these had different rules for unmasking values, and even different
arguments to decide how to do so.
Fixes #8664
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Fixes #5846 (If called with an empty array as first argument, the returned
array had dtype bool instead of the dtype of the input array)
|
|
|
|
|
| |
The call to `empty_like` was trying to use the `chararray` subclass,
which doesn't support the `np.intp` dtype.
|
|
|
|
|
|
|
| |
The possibly controversial part of this is making the nested array
value lists PEP8 compliant, as there is something to be said aligning
the values for clarity. In the end, it seemed like the easiest thing
to do was to make them PEP8 compliant. The eye can get used to that.
|
| |
|
|
|
|
|
|
|
|
| |
np.unique produces wrong results when passed a list of tuples and
no keyword arguments, as it fails to recognize it as a multidim
array, but handles it as a 1D array of objects. The only way around
this seems to be to completely eliminate the fast path for non-array
inputs using `set`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR adds a new keyword argument to `np.unique` that returns the
number of times each unique item comes up in the array. This allows
replacing a typical numpy construct:
unq, _ = np.unique(a, return_inverse=True)
unq_counts = np.bincount(_)
with a single line of code:
unq, unq_counts = np.unique(a, return_counts=True)
As a plus, it runs faster, because it does not need the extra
operations required to produce `unique_inverse`.
|
|
|
|
|
| |
Use `np.sort` instead of `sorted` when the input is a list and no indices
are requested. Fixes #2799.
|
|
|
|
|
|
|
| |
Run autopep8 over the test files in numpy/lib/test and make fixes
to the result.
Also remove Python5 workaround.
|
|
|
|
|
|
|
| |
Run the 2to3 ws_comma fixer on *.py files. Some lines are now too long
and will need to be broken at some point. OTOH, some lines were already
too long and need to be broken at some point. Now seems as good a time
as any to do this with open PRs at a minimum.
|
|
|
|
|
|
|
|
|
|
| |
In Python 3 zip returns an iterator instead of a list. Consequently, in
places where an iterator won't do it must be enclosed in list(...).
Lists instead of iterators are also used in array constructors as using
iterators there usually results in an object array containing an
iterator object.
Closes #3094
|
| |
|
|
|
|
|
|
|
| |
Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.
Closes #3078.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new import `absolute_import` is added the `from __future__ import`
statement and The 2to3 `import` fixer is run to make the imports
compatible. There are several things that need to be dealt with to make
this work.
1) Files meant to be run as scripts run in a different environment than
files imported as part of a package, and so changes to those files need
to be skipped. The affected script files are:
* all setup.py files
* numpy/core/code_generators/generate_umath.py
* numpy/core/code_generators/generate_numpy_api.py
* numpy/core/code_generators/generate_ufunc_api.py
2) Some imported modules are not available as they are created during
the build process and consequently 2to3 is unable to handle them
correctly. Files that import those modules need a bit of extra work.
The affected files are:
* core/__init__.py,
* core/numeric.py,
* core/_internal.py,
* core/arrayprint.py,
* core/fromnumeric.py,
* numpy/__init__.py,
* lib/npyio.py,
* lib/function_base.py,
* fft/fftpack.py,
* random/__init__.py
Closes #3172
|
|
|
|
|
|
|
|
| |
This should be harmless, as we already are division clean. However,
placement of this import takes some care. In the future a script
can be used to append new features without worry, at least until
such time as it exceeds a single line. Having that ability will
make it easier to deal with absolute imports and printing updates.
|
|
|
|
|
|
| |
The behavior of in1d is not really defined here, but it should
be at least consistent over different execution branches. This is
what it has been for most usages.
|
|
|
|
|
|
|
|
|
| |
There was a regression introduced by the speed improvement in
commit 6441c2a. This fixes it, and generally ravels the arrays for
np.in1d. However it can be argued that at least the first array should
not be ravelled in the future.
Fixes "Issue gh-2755"
|
|
|
|
|
|
|
|
| |
Small arrays are sorted with insertion sort, which is a stable
sort. Consequently larger arrays are needed to check that the
sort used is properly stable.
The test was also refactored to make it more compact.
|
| |
|
|
|
|
|
|
| |
A timing script justifying the switching criterion is attached to ticket 1603.
Thanks to Neil Crighton.
|
| |
|
|
|
|
| |
not modify user defined filters.
|