8000 NEP: add NEP 56 on array API standard support in main namespace by rgommers · Pull Request #25542 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

NEP: add NEP 56 on array API standard support in main namespace #25542

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 16 commits into from
Feb 28, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
NEP: update description of fft changes
[skip actions] [skip cirrus] [skip azp]
  • Loading branch information
rgommers committed Feb 20, 2024
commit 115cf775e481fd56f6c7f3e1ee08de4b958f59cc
23 changes: 15 additions & 8 deletions doc/neps/nep-0056-array-api-main-namespace.rst
Original file line number Diff line number Diff line change
Expand Up @@ -234,7 +234,8 @@ categories:
2. Dtypes of returned arrays for some element-wise functions and reductions,
3. Numerical behavior for a few tolerance keywords,
4. Functions moved to ``numpy.linalg`` and supporting stacking/batching,
5. The semantics of the ``copy`` keyword in ``asarray`` and ``array``.
5. The semantics of the ``copy`` keyword in ``asarray`` and ``array``,
6. Changes to ``numpy.fft`` functionality.

**Raising errors for consistency/strictness includes**:

Expand Down Expand Up @@ -303,17 +304,23 @@ to be* ``np.array(..., copy=False)``, *because until a few years ago that had
lower overhead than* ``np.asarray(...)``. *This was solved though, and*
``np.asarray(...)`` *is idiomatic NumPy usage.*

**Other changes**: there may be a few other changes that don't quite fall in
one of the categories above. For example, ``numpy.fft`` functions need to
**Changes to numpy.fft**: all functions in the ``numpy.fft`` submodule need to
preserve precision for 32-bit input dtypes rather than upcast to
``float64``/``complex128`` (desirable anyway, and can be supported with the new
gufunc implementation in (`gh-25336
<https://github.com/numpy/numpy/pull/25336>`__) . Also in 7019 ``numpy.fft``,
there's an issue with the ``s``/``axes`` argument in n-D transforms that needs
solving (see `gh-25495 <https://github.com/numpy/numpy/pull/25495>`__).
``float64``/``complex128``. This is a desirable change, consistent with the design
of NumPy as a whole - but it's possible that the lower precision or the dtype of
the returned arrays from calls to functions in this module may affect users.
This change was made by via a new gufunc-based implementation and vendoring of the
C++ version of PocketFFT in (`gh-25711 <https://github.com/numpy/numpy/pull/25711>`__).

A smaller backwards-incompatible change to ``numpy.fft`` is to make the
behavior of the ``s`` and ``axes`` arguments in n-D transforms easier to
understand by disallowing ``None`` values in ``s`` and requiring that if ``s``
is used, ``axes`` must be specified as well (see
`gh-25495 <https://github.com/numpy/numpy/pull/25495>`__).

*We expect the impact of this category of changes to be small.*


Adapting to the changes & tooling support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Expand Down
0