| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
| |
For regular arrays, we now give a deprecation warning if
np.positive cannot handle it; for ndarray subclasses that override
__array_ufunc__, we pass on the type error.
|
| |\
| |
| | |
ENH: Add AARCH32 support.
|
| | |
| |
| |
| |
| | |
This adds support for identifying AARCH32 and AARCH64 at compile
time such that alignment etc is correctly determined.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the index array was non contiguous and not 1D the assignment
1D fastpath (indexed array being 1D) was incorrectly taken (also
the assignment value had to be 0D for this to happen).
This caused the iteration to use the itemsize as a stride, since
it incorrectly assumed the array must be contiguous.
The commit additionally adds an assert to the STRIDE fetching macro.
Closes gh-11467.
|
| | |
| |
| |
| |
| | |
Code was getting too convoluted and both can be optimized
in different ways.
|
| |/
|
|
|
|
|
| |
Overall, it likely doesn't matter much for performance, but it is
more logical and more consistent with what python does: reverse
operators are not called if the forward one of a given class
already returned NotImplemented.
|
| |
|
|
|
| |
PyObject_Type increases the reference count, which was not taken
into account.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
BUG: Fix missing NPY_VISIBILITY_HIDDEN on npy_longdouble_to_PyLong
|
| | |
| |
| |
| |
| |
| | |
Fixes #10648
NPY_VISIBILITY_HIDDEN is used by memoverlap.{c,h}, so we should be using the same thing here
|
| | |
| |
| |
| |
| |
| |
| | |
The gcc compiler treats enums as unsigned unless one of the enumerated
values is negative. The values are small, so we can fix that by casting
to int. The same can be done with the results of the sizeof function if
we know ahead of time that the result is small.
|
| | | |
|
| | |
| |
| |
| |
| | |
The gcc sign-compare warning is enabled in Python 3.5+ and causes errors
in the wheel builds.
|
| |/
|
|
|
|
|
|
| |
The test was failing on Darwin due to Apple's defective pow function.
The fix here is to generate the huge longdouble that is tested in a way
that avoids the problems of the pow function.
The C++ comments in npy_longdouble.c are also fixed.
|
| |
|
|
|
|
| |
Implements a custom PyLong_FromLongDouble (with a different name) derived from PyLong_FromDouble.
Fixes gh-9964
|
| |
|
|
|
| |
Removes _POSIX_C_SOURCE redefine warnings. Standard library headers
should always be included last.
|
| |
|
|
|
| |
Similarly to hypot() also cabs* on MSVC/win32 mess with floating point
mode.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Previously, we would check if the attribute existed on the class, yet use it from the instance.
This also cuts 3 lookups of `__array_ufunc__` down to one.
|
| |
|
|
| |
This also corrects a broken short-circuit when looking up __array_ufunc__
|
| | |
|
| |\
| |
| | |
BUG: `__array_ufunc__= None` -> TypeError
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
For backward compatibility, we need to let `__array_priority__`
determine the override for inplace ops. If `__array_ufunc__ = None`
on the right hand side it is still the case that TypeError will be
raised.
This fixes SciPy test failures of the type
ndarray += sparse_array
Closes #9019.
|
| |
|
|
|
|
|
| |
And put it in src/umath instead of src/private. This leaves only
the PyUFunc_WithOverride function in ufunc_override.c, which is all
that is needed outside of umath (it is called by array_ufunc in
multiarray/methods.c).
|
| |
|
|
|
| |
In particular, use fact that we're guaranteed to have a PyUFuncObject
in PyUFunc_CheckOverride.
|
| |
|
|
|
|
|
| |
As part of this, it turns out the number of output arguments nout
was needed, so that was passed in. Also, testing showed that arguments
passed in both as positional and keyword arguments were not caught,
so a duplication check was added.
|
| |
|
|
|
|
| |
As part of this, split off the checking for overrides from the actual
trying to execute them (in ufunc_override.c), so that just the check
can be done in ndarray.__array_ufunc__.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
In previous versions, one could force ndarray binops to defer by
setting a high __array_priority__. With __array_ufunc__ this gets
ignored, and this commit ensures it is still possible to avoid
using the standard python language feature that setting something
to None means it is not implemented. In consequence, inside a
ufunc, if __array_ufunc__ is None, it will be treated as if it
had returned NotImplemented (leading to a TypeError if no other
object had a functioning __array_ufunc__ override).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As per the discussion at gh-5844, and in particular
https://github.com/numpy/numpy/issues/5844#issuecomment-112014014
this commit switches binop dispatch to mostly defer to ufuncs, except
in some specific cases elaborated in a long comment in number.c.
The basic strategy is to define a single piece of C code that knows
how to handle forward binop overrides, and we put it into
private/binop_override.h so that it can be accessed by both the array
code in multiarray.so and the scalar code in umath.so.
|
| |
|
|
|
| |
This is an ugly kluge, but until we merge multiarray.so and umath.so
moving stuff into private/*.h serves as a reasonable workaround.
|
| |
|
|
|
|
| |
Previously when __array_ufunc__ for one of the ufunc arguments was
called, that arguments position was passed in the call. This PR removes
that argument as proposed in gh-5986.
|
| |
|
|
|
|
|
|
| |
The first commit in changing __numpy_ufunc__ by removing the index
argument and making the out argument value always a tuple. These changes
were proposed in gh-5986 and have been accepted. Renaming before further
changes avoids triggering tests in scipy and astropy while keeping the
numpy tests working.
|
| |
|
|
|
| |
This reverts commit bac094caf14e420a801cf952080aa443a3865d97 and enables
__numpy_ufunc__ for development in the NumPy 1.13.0 development cycle.
|
| | |
|
| |
|
|
|
|
|
|
| |
Arrays with zero strides are never "ahead", as the same element is
reused multiple times.
The previous logic was incorrect eg. for stride1==0, stride2<0 and
arr1->data==arr2->data.
|
| | |
|
| | |
|
| |
|
|
|
| |
These loops iterate over whole arrays in "trivial" order, so that it is
possible to reason about the data dependency.
|