| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
(#11813)
Fixes #11809.
* BUG: fix array_split incorrect behavior with array size bigger MAX_INT32
* TST: added test for array_split with array size greater MAX_INT32
* addressed review comments
|
|
|
|
| |
This allows np.ma.expand_dims to be removed
|
|
|
|
| |
This is the reduced version that does not allow any insertion of extra dimensions
|
| |
|
|\
| |
| | |
DOC: describe the expansion of take and apply_along_axis in detail
|
| |
| |
| |
| |
| |
| | |
Extracted from gh-8714
[ci-skip]
|
|/
|
|
| |
[ci skip]
|
|
|
| |
Before this addition, people could expect that only the last sub-array would have a different size. The added documentation and example make clear what the function really does.
|
| |
|
|
|
|
| |
[skip ci]
|
|
|
|
|
|
|
|
|
|
|
| |
Expand_dims works as documented when the index of the inserted NewAxis
in the resulting array satisfies -a.ndim - 1 <= index <= a.ndim.
However, when index > a.ndim index is replaced by a.ndim and, when
index < -a.ndim - 1, it is replaced by index + a.ndim + 1, which may be
negative and results in incorrect placement. The latter two cases are
now deprecated.
Closes #9100.
|
|
|
|
| |
[ci skip]
|
| |
|
|\
| |
| | |
BUG: Fix double-wrapping of object scalars
|
| |
| |
| |
| | |
Fixes #8642
|
|\ \
| | |
| | | |
DOC: Mention that expand_dims and squeeze are inverses
|
| | |
| | |
| | |
| | | |
[ci skip]
|
|/ /
| |
| | |
This adds to the documentation on `dstack` the notes from `hstack` and `vstack` about dimensionality requirements.
|
| | |
|
|/
|
|
|
|
|
| |
As a result, some exceptions change from ValueError to IndexError
This also changes the exception types raised in places where
normalize_axis_index is not quite appropriate
|
|
|
|
| |
Fixes #7454
|
|
|
|
| |
Copied from the implementation in core.shape_base.stack
|
|
|
|
|
|
|
| |
.transpose does not specify that it must return a view, so subclasses
(like np.ma.array) could otherwise break this.
This exposes some more need for matrix special casing.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Also:
ENH: Support arbitrary dimensionality of return value
MAINT: remove special casing
|
|
|
|
|
|
|
|
|
|
|
|
| |
* BUG: Closes issue #8419
Fixes issue in apply_along_axis() where func1d() returns a non ndarray
* BUG: Fix apply_along_axis() when func1d() returns a non-ndarray
Closes issue #8419. Fixes issue in apply_along_axis() where
func1d() returns a non ndarray by calling asanyarray() on
result. This commit fixes a too long line in the test case.
|
|
|
|
|
|
|
| |
This commit modifies the numpy.apply_along_axis() function so that if
it is called with an ndarray subclass, the internal func1d calls
receive subclass instances and the overall function returns an instance
of the subclass. There are two new tests for these two behaviours.
|
|
|
|
|
| |
The missing whitespace lead to inconsistent rendering in the
online documentation. [ci skip]
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously an empty array resulting from split always had dimension 1-D.
In Numpy 1.9 a FutureWarning was raised to notify users that it was
planned to preserve the dimensions of empty arrays in a future numpy
release. This removes the FutureWarning and implements preservation of
dimensions.
Note that there was a bug in numpy 1.9 and the dimensions of empty
arrays was already preserved in some cases and no warning was issued.
This PR fixes that inconsistency by preserving the dimensions in all
cases rather than fixing the bug, as the dimension preserving behavior
was already depended on by some users. See the discussion in gh-6575
about this change.
|
|\
| |
| | |
BUG: Make sure warning for array split is always applied
|
| |
| |
| |
| |
| |
| |
| |
| | |
Zero arrays can also occur with any of the partitions sub_arys[i]
induced by array_split, not just the final partition sub_arys[-1].
Modified by seberg.
Closes gh-5771
|
| | |
|
|\ \
| |/
|/| |
ENH: add np.stack
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The motivation here is to present a uniform and N-dimensional interface for
joining arrays along a new axis, similarly to how `concatenate` provides a
uniform and N-dimensional interface for joining arrays along an existing axis.
Background
~~~~~~~~~~
Currently, users can choose between `hstack`, `vstack`, `column_stack` and
`dstack`, but none of these functions handle N-dimensional input. In my
opinion, it's also difficult to keep track of the differences between these
methods and to predict how they will handle input with different
dimensions.
In the past, my preferred approach has been to either construct the result
array explicitly and use indexing for assignment, to or use `np.array` to
stack along the first dimension and then use `transpose` (or a similar method)
to reorder dimensions if necessary. This is pretty awkward.
I brought this proposal up a few weeks on the numpy-discussion list:
http://mail.scipy.org/pipermail/numpy-discussion/2015-February/072199.html
I also received positive feedback on Twitter:
https://twitter.com/shoyer/status/565937244599377920
Implementation notes
~~~~~~~~~~~~~~~~~~~~
The one line summaries for `concatenate` and `stack` have been (re)written to
mirror each other, and to make clear that the distinction between these functions
is whether they join over an existing or new axis.
In general, I've tweaked the documentation and docstrings with an eye toward
pointing users to `concatenate`/`stack`/`split` as a fundamental set of basic
array manipulation routines, and away from
`array_split`/`{h,v,d}split`/`{h,v,d,column_}stack`
I put this implementation in `numpy.core.shape_base` alongside `hstack`/`vstack`,
but it appears that there is also a `numpy.lib.shape_base` module that contains
another larger set of functions, including `dstack`. I'm not really sure where
this belongs (or if it even matters).
Finally, it might be a good idea to write a masked array version of `stack`.
But I don't use masked arrays, so I'm not well motivated to do that.
|
| |
| |
| | |
So removed the paranthesis and included the return statement.
|
|/
|
|
|
| |
Tile now copies the input when it is a numpy array and all dimensions are
repeated only once.
|
|
|
|
| |
This bug was reported in Debian as: http://bugs.debian.org/777172 .
|
|
|
|
| |
The rules enforced are the same as those used for scipy.
|
|
|
|
|
|
| |
Some of those problems look like potential coding errors. In those
cases a Fixme comment was made and the offending code, usually an
unused variable, was commented out.
|
|\
| |
| | |
ENH: apply_along_axis accepts named arguments
|
| | |
|
| | |
|
|/
|
|
|
|
|
| |
Remove misleading note about equivalency betwen column_stack and
np.vstack(tup).T.
Fixes #3488
|
| |
|