Repository navigation
NumPy 1.24 - #8691
NumPy 1.24#8691
Conversation
I believe this was written in error and should always have been float16.
This test only checked for a plain match when comparing outputs. However, in some cases a reconstruction check can be necessary, as in `test_linalg_svd`.
Setting an array element with a sequence is removed in NumPy 1.24.
The modified regex matches the existing message produced by NumPy < 1.24, and the new improved message in 1.24.
This always produced invalid results (though they were consistent between Numba and NumPy) but now this fails in NumPy 1.24 with an exception: ``` TypeError: The `dtype` and `signature` arguments to ufuncs only select the general DType and not details such as the byte order or time unit. You can avoid this error by using the scalar types `np.float64` or the dtype string notation. ``` Note that the exception message is misleading, and using the dtype string notation does not provide a workaround.
np.bool was removed in NumPy 1.24.
The API version has long since been greater than 0x7 / 0x8 for any supported NumPy.
If an unexpected ufunc method was encountered, `init_ufunc_dispatch()` would return an error code indicating failure without setting an exception, leading to errors like ``` SystemError: initialization of _internal failed without raising an exception ``` as reported in Issue numba#8615. This commit fixes the issue by setting an appropriate exception in this case.
NumPy 1.24 adds a new method, `resolve_dtypes()`, and a private method `_resolve_dtypes_and_context()`. We handle these by just ignoring them (ignoring all private methods in general) in order to provide the same level of functionality in Numba as for NumPy 1.23. There is further room to build new functionality on top of this: - Providing an implementation of `resolve_dtypes()` for `DUFunc` objects. - Using the `resolve_dtypes()` method in place of logic in Numba that implements a similar dtype resolution process.
This results in the following output from `print_azure_matrix()`: ``` NumPy | Python | Count ----------------------- 1.21 | 3.8 | 4 1.22 | 3.8 | 4 1.22 | 3.9 | 1 1.23 | 3.8 | 2 1.23 | 3.9 | 2 1.23 | 3.10 | 1 1.24 | 3.10 | 3 1.24 | 3.8 | 1 1.24 | 3.9 | 1 ``` There are 19 slices, so the aim was to have five slices for each NumPy version (1.21, 1.22, 1.23, 1.24) except for 1.21 which has 4 slices.
Just a drive-by comment/idea to potentially unblock progress here: you could use the |
Thanks for the suggestion - #8620 tests all slices against 1.24. I don't want to change the setup for this PR, because this PR is in the form I'd like reviewed and eventually merged. |
|
(At the time I set up #8620, there were no conda-forge packages either because the first 1.24 RC had just been released, so it uses pip) |
DrTodd13
left a comment
There was a problem hiding this comment.
Fine with the parfor related part of this PR.
stuartarchibald
left a comment
There was a problem hiding this comment.
Thanks for the patch @gmarkall, the organised commits/commit messages were very helpful in review. There's a few minor suggestions/things to look at in the review but otherwise looks good. I've checked the Azure config update and it looks like it has a good spread of NumPy versions (roughly 5 builds per supported NumPy version).
|
Ah, a merge from |
|
gpuci run tests |
|
Hello! Would be great to see this PR merged:) I'm totally unfamiliar with |
|
@SomeoneSerge, we have decided to do something like that. We are now relying on conda-forge for testing the latest dependency. Good news is that this PR has already pass tests on linux-64 in our buildfarm. Just waiting for the rest to complete to merge this PR. |
|
This PR has passed all 64-bit platforms. 32-bit platform failures are so far buildfarm issues. |
|
We just need to get AzureCI to use conda-forge for np1.24 |
|
gpuci run tests |
|
gpuci run tests |
stuartarchibald
left a comment
There was a problem hiding this comment.
The changes to the public CI configuration since the last approval look as expected for use of conda-forge NumPy packages for NumPy version 1.24. Thanks for making this adjustment @gmarkall.
|
Public CI failed due to timeout on windows. We can safely ignore the failure given it passed on buildfarm already. |
- np.int, np.bool, np.float is depreciated in v1.20 in favour of np.int_, np.bool_, np.float_ Waiting on some dependencies to update: - numba not yet compatible with numpy 1.24 > from numba.np.ufunc import _internal E SystemError: initialization of _internal failed without raising an exception - numba/numba#8464 - numba/numba#8691 - numba/numba#8841 - https://github.com/numba/numba/milestone/63 - [x] Waiting for next numba release with numpy 1.24 support. --------- Co-authored-by: John Pocock <John-P@users.noreply.github.com>
This PR updates Numba to support NumPy 1.24, and is ready for review. Presently CI will fail due to the lack of NumPy 1.24 packages in Anaconda, but this should be resolved in time.
Each individual commit message details the changes made and their rationale - each should be reviewable as an individual change.
See testing with two other PRs: