| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Fix a false mismatch. Separate dtype objects, even if equivalent,
cause distinct array views to be created.
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Use the correct API call to actually set the base object.
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
For `asarray` and for the `dtype` equality operator,
equivalent dtype aliases were considered exact matches.
This change ensures that the returned array has a descriptor
that exactly matches the requested dtype.
Note: Intended behavior of `np.dtype('i') == np.dtype('l')`
is to test compatibility, not identity. This change does not
affect the behavior of `PyArray_EquivTypes()`, and the
`__eq__` operator for `dtype` continues to map to
`PyArray_EquivTypes()`.
Fixes #1468.
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
* Fix the implementation of numpy.array_api.vecdot
See https://data-apis.org/array-api/latest/API_specification/generated/signatures.linear_algebra_functions.vecdot.html
* Use moveaxis + matmul instead of einsum in vecdot
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
TST: ensure `np.equal.reduce` raises a `TypeError`
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
If we cache a promoted version of the loop, that promoted can mismatch
the correct one. This ends up being rejected later in the legacy paths
(should be the only path currently used), but we should reject it here
(or in principle we could reject it after cache lookup, but we are fixing
up the operation DTypes here anyway, so we are looking at the signature).
A call sequence reproducing this directly is:
np.add(1, 2, signature=(bool, int, None)) # should fail
np.add(True, 2) # A promoted loop
np.add(1, 2, signature=(bool, int, None)) # should still fail
Not that the errors differ, because the first one comes from the old
type resolution code and is currently less precise
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Since Python 3.8, the default start method for multiprocessing has been changed from fork to spawn on macOS
The default start method is still fork on other Unix platforms[1], causing inconsistency on memory sharing model
It will cause a memory-sharing problem for the test test_large_zip on macOS as the memory sharing model between spawn and fork is different
The fix
Change the start method for this test back to fork under this testcase context
In this test case context, the bug that caused default start method changed to spawn for macOS will not be triggered
It is context limited, so this change will not affect default start method other than test_large_zip
All platforms have the same memory sharing model now
After the change, test_large_zip is passed on macOS
https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods
Closes gh-22203
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Closes #22185
The __class_getitem__ implementations would previously perform basic validation of the passed value, i.e. it would check whether a tuple of the appropriate length was passed (e.g. np.dtype.__class_getitem__ would expect a single item or a length-1 tuple). As noted in aforementioned issue: this approach can cause issues when (a. 2 or more parameters are involved and (b. a subclasses is created one or more parameters are declared constant (e.g. a fixed dtype & variably shaped array).
This PR fixes aforementioned issue by relaxing the runtime argument validation, thus mimicking the behavior of the standard library (more closely). While we could alternatively fix this by adding more special casing (e.g. only disable validation when cls is not np.ndarray), I'm not convinced this would be worth the additional complexity, especially since the standard library also has zero runtime validation for all of its Py_GenericAlias-based implementations of __class_getitem__.
(Some edits by seberg to the commit message)
|
|\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
BUG: change overloads to play nice with pyright.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Pyright just chooses the first matching type whenever there is ambiguity in type resolution, which leads to NoReturn for the cross function in certain situations. Other overloads were changed to match. See ticket #22146
|
|\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
DOC: Note symmetry requirement in `multivariate_normal` error
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
numpy.random.multivariate_normal more descriptive (closes #22140)
Issue #22140 says that numpy.random.multivariate_normal incorrectly warns that a non-symmetric positive-semidefinite matrix isn't positive-semidefinite. In the replies, there was some ambiguity over whether it was possible for a positive-semidefinite matrix to be non-symmetric, with reliable sources saying that symmetry is a common condition to add but not actually necessary. To solve this problem, two different members of the Numpy organization decided that the warning and error message "covariance is not positive-semidefinite" should be changed to "covariance is not symmetric positive-semidefinite". However, this change was never actually made yet.
Since this change only required me to change a few strings instead of actually changing the code, I've decided to skip the CI jobs.
[skip ci]
|
| | | | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
BUG: fix np.average for Fraction elements
|
| | | | | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ \
| |_|_|/ / / / / / / / / / /
|/| | | | | | | | | | | | | |
BUG: Expose string_heapsort algorithm in a shared header
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Fix #22011
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
This was giving many warnings like this one in the SciPy build:
```
scipy/special/_specfunmodule.c: In function 'complex_double_from_pyobj':
scipy/special/_specfunmodule.c:198:47: warning: passing argument 1 of 'PyArray_DATA' from incompatible pointer type [-Wincompatible-pointer-types]
198 | (*v).r = ((npy_cdouble *)PyArray_DATA(arr))->real;
| ^~~
| |
| PyObject * {aka struct _object *}
In file included from /home/rgommers/code/numpy/numpy/core/include/numpy/ndarrayobject.h:12,
from /home/rgommers/code/numpy/numpy/core/include/numpy/arrayobject.h:5,
from /home/rgommers/code/numpy/numpy/f2py/src/fortranobject.h:16,
from scipy/special/_specfunmodule.c:22:
/home/rgommers/code/numpy/numpy/core/include/numpy/ndarraytypes.h:1524:29: note: expected 'PyArrayObject *' {aka 'struct tagPyArrayObject *'} but argument is of type 'PyObject *' {aka 'struct _object *'}
1524 | PyArray_DATA(PyArrayObject *arr)
| ~~~~~~~~~~~~~~~^~~
```
Fixing pointer mismatches is important for Pyodide/Emscripten.
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
TST: Implemented an unused test for np.random.randint
|
| | |_|/ / / / / / / / / / /
| |/| | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
In numpy/random/tests/test_random.py, a class called TestSingleEltArrayInput had a method called test_randint that was commented out, with the instructions to uncomment it once np.random.randint was able to broadcast arguments. Since np.random.randint has been able to broadcast arguments for a while now, I uncommented the test. The only modification I made to the code was fixing a small error, where the author incorrectly tried to call "assert_equal" as a method of the TestSingleEltArrayInput instead of a function that was imported from numpy.testing. I ran runtests.py, and the new test passed.
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ \
| |/ / / / / / / / / / / / /
|/| | | | | | | | | | | | | |
BUG: Support using libunwind for backtrack
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Some system (e.g. musl) do not have "execinfo.h", and the backtracking
is provided by libunwind.
Fix: #22084
|
| |_|_|_|_|_|/ / / / / / /
|/| | | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
MAINT: Simplify npymath
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
generated
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Signed-off-by: mattip <matti.picus@gmail.com>
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Signed-off-by: mattip <matti.picus@gmail.com>
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
|/ / / / / / / / / / / / /
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
This PR replaces the import of platform and a call to platform.python_implementation() with a check using sys.implementation.name to improve the numpy import time. The improvement is about 5-10 ms (system dependent).
Also see #22061
Co-authored-by: Matti Picus <matti.picus@gmail.com>
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
[ci skip]
|
|\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
ENH: Use `threadpoolctl` in `show_runtime` (a new function)
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|