On this page
Array API Standard Compatibility
Note
The numpy.array_api
module is still experimental. See NEP 47.
NumPy includes a reference implementation of the array API standard in numpy.array_api
. NEP 47 describes the motivation and scope for implementing the array API standard in NumPy.
The numpy.array_api
module serves as a minimal, reference implementation of the array API standard. In being minimal, the module only implements those things that are explicitly required by the specification. Certain things are allowed by the specification but are explicitly disallowed in numpy.array_api
. This is so that the module can serve as a reference implementation for users of the array API standard. Any consumer of the array API can test their code against numpy.array_api
and be sure that they aren’t using any features that aren’t guaranteed by the spec, and which may not be present in other conforming libraries.
The numpy.array_api
module is not documented here. For a listing of the functions present in the array API specification, refer to the array API standard. The numpy.array_api
implementation is functionally complete, so all functionality described in the standard is implemented.
Table of Differences between numpy.array_api
and numpy
This table outlines the primary differences between numpy.array_api
from the main numpy
namespace. There are three types of differences:
- Strictness. Things that are only done so that
numpy.array_api
is a strict, minimal implementation. They aren’t actually required by the spec, and other conforming libraries may not follow them. In most cases, spec does not specify or require any behavior outside of the given domain. The mainnumpy
namespace would not need to change in any way to be spec-compatible for these. - Compatible. Things that could be added to the main
numpy
namespace without breaking backwards compatibility. - Breaking. Things that would break backwards compatibility if implemented in the main
numpy
namespace.
Name Differences
Many functions have been renamed in the spec from NumPy. These are otherwise identical in behavior, and are thus all compatible changes, unless otherwise noted.
Function Name Changes
The following functions are named differently in the array API
Array API name |
NumPy namespace name |
Notes |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is breaking because |
|
|
|
|
|
|
|
|
Unlike |
|
|
|
|
|
Each is equivalent to |
Function instead of method
astype
is a function in the array API, whereas it is a method onndarray
innumpy
.
linalg
Namespace Differences
These functions are in the linalg
sub-namespace in the array API, but are only in the top-level namespace in NumPy:
cross
diagonal
matmul
(*)outer
tensordot
(*)trace
(*): These functions are also in the top-level namespace in the array API.
Keyword Argument Renames
The following functions have keyword arguments that have been renamed. The functionality of the keyword argument is identical unless otherwise stated. Each new keyword argument is not already present on the given function in numpy
, so the changes are compatible.
Note, this page does not list function keyword arguments that are in the main numpy
namespace but not in the array API. Such keyword arguments are omitted from numpy.array_api
for strictness, as the spec allows functions to include additional keyword arguments from those required.
Function |
Array API keyword name |
NumPy keyword name |
Notes |
---|---|---|---|
|
|
|
The definitions of |
|
|
|
The definitions of |
|
|
|
The definitions of |
|
|
|
Type Promotion Differences
Type promotion is the biggest area where NumPy deviates from the spec. The most notable difference is that NumPy does value-based casting in many cases. The spec explicitly disallows value-based casting. In the array API, the result type of any operation is always determined entirely by the input types, independently of values or shapes.
Feature |
Type |
Notes |
---|---|---|
Limited set of dtypes. |
Strictness |
|
Operators (like |
Strictness |
For example, |
Operators (like |
Breaking |
For example, |
In-place operators are disallowed when the left-hand side would be promoted. |
Breaking |
Example: |
|
Strictness |
|
|
Breaking |
For example, |
No cross-kind casting. |
Strictness |
Namely, boolean, integer, and floating-point data types do not cast to each other, except explicitly with |
No casting unsigned integer dtypes to floating dtypes (e.g., |
Strictness |
|
|
Strictness |
The |
|
Breaking |
Indexing Differences
The spec requires only a subset of indexing, but all indexing rules in the spec are compatible with NumPy’s more broad indexing rules.
Feature |
Type |
Notes |
---|---|---|
No implicit ellipses ( |
Strictness |
If an index does not include an ellipsis, all axes must be indexed. |
The start and stop of a slice may not be out of bounds. |
Strictness |
For a slice
|
Boolean array indices are only allowed as the sole index. |
Strictness |
|
Integer array indices are not allowed at all. |
Strictness |
With the exception of 0-D arrays, which are treated like integers. |
Type Strictness
Functions in numpy.array_api
restrict their inputs to only those dtypes that are explicitly required by the spec, even when the wrapped corresponding NumPy function would allow a broader set. Here, we list each function and the dtypes that are allowed in numpy.array_api
. These are strictness differences because the spec does not require that other dtypes result in an error. The categories here are defined as follows:
- Floating-point:
float32
orfloat64
. - Integer: Any signed or unsigned integer dtype (
int8
,int16
,int32
,int64
,uint8
,uint16
,uint32
, oruint64
). - Boolean:
bool
. - Integer or boolean: Any signed or unsigned integer dtype, or
bool
. For two-argument functions, both arguments must be integer or both must bebool
. - Numeric: Any integer or floating-point dtype. For two-argument functions, both arguments must be integer or both must be floating-point.
- All: Any of the above dtype categories. For two-argument functions, both arguments must be the same kind (integer, floating-point, or boolean).
In all cases, the return dtype is chosen according to the rules outlined in the spec, and does not differ from NumPy’s return dtype for any of the allowed input dtypes, except in the cases mentioned specifically in the subsections below.
Elementwise Functions
Function Name |
Dtypes |
---|---|
|
Numeric |
|
Floating-point |
|
Floating-point |
|
Numeric |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Integer or boolean |
|
Integer or boolean |
|
Integer |
|
Integer or boolean |
|
Integer |
|
Integer or boolean |
|
Numeric |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
All |
|
Floating-point |
|
Floating-point |
|
Numeric |
|
Numeric |
|
Numeric |
|
Numeric |
|
Numeric |
|
Numeric |
|
Numeric |
|
Numeric |
|
Numeric |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Boolean |
|
Boolean |
|
Boolean |
|
Boolean |
|
Numeric |
|
Numeric |
|
All |
|
Numeric |
|
Numeric |
|
Numeric |
|
Numeric |
|
Numeric |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Numeric |
|
Numeric |
|
Floating-point |
|
Floating-point |
|
Numeric |
(*) These functions have different names from the main numpy
namespace. See Function Name Changes.
Creation Functions
Function Name |
Dtypes |
---|---|
|
Any (all input dtypes must be the same) |
Linear Algebra Functions
Function Name |
Dtypes |
---|---|
|
Floating-point |
|
Numeric |
|
Floating-point |
|
Any |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Numeric |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Any |
|
Numeric |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Floating-point |
|
Numeric |
|
Numeric |
|
Numeric |
|
Floating-point |
(*) Thes functions are split from norm
from the main numpy
namespace. See Function Name Changes.
(**) These functions are new in the array API and are not in the main numpy
namespace.
Array Object
All the special __operator__
methods on the array object behave identically to their corresponding functions (see the spec for a list of which methods correspond to which functions). The exception is that operators explicitly allow Python scalars according to the rules outlined in the spec (see Type Promotion Differences).
Array Object Differences
Feature |
Type |
Notes |
---|---|---|
No array scalars |
Strictness |
The spec does not have array scalars, only 0-D arrays. However, other than the promotion differences outlined in Type Promotion Differences, scalars duck type as 0-D arrays for the purposes of the spec. The are immutable, but the spec does not require mutability. |
|
Strictness |
|
|
Compatible |
|
The |
Compatible |
See the spec definition for |
The |
Breaking |
See the note in the spec. |
New method |
Compatible |
The methods would effectively not do anything since NumPy is CPU only |
Creation Functions Differences
Feature |
Type |
Notes |
---|---|---|
|
Compatible |
|
New |
Compatible |
|
Elementwise Functions Differences
Feature |
Type |
Notes |
---|---|---|
Various functions have been renamed. |
Compatible |
|
Elementwise functions are only defined for given input type combinations. |
Strictness |
See Type Strictness. |
|
Strictness |
|
|
Breaking |
|
Linear Algebra Differences
Feature |
Type |
Notes |
---|---|---|
|
Compatible |
|
|
Breaking |
|
|
Breaking |
Strictly speaking this can be compatible because |
|
Compatible |
The corresponding |
New functions |
Compatible |
The |
|
Breaking |
In the array API, |
|
Breaking |
|
New function |
Compatible |
Unlike |
|
Breaking |
The spec currently only specifies behavior on 1-D arrays but future behavior will likely be to broadcast, rather than flatten, which is what |
|
Breaking |
The meaning of |
|
Breaking |
The |
New function |
Compatible |
Equivalent to |
The |
Compatible |
In |
|
Breaking |
|
Manipulation Functions Differences
Feature |
Type |
Notes |
---|---|---|
Various functions have been renamed |
Compatible |
|
|
Strictness |
No cross-kind casting. No value-based casting on scalars (when axis=None). |
|
Strictness |
No cross-kind casting. |
New function |
Compatible |
Unlike |
|
Compatible |
Set Functions Differences
Feature |
Type |
Notes |
---|---|---|
New functions |
Compatible |
|
The four |
Compatible |
|
|
Compatible |
Set Functions Differences
Feature |
Type |
Notes |
---|---|---|
|
Breaking |
|
|
Compatible |
Statistical Functions Differences
Feature |
Type |
Notes |
---|---|---|
|
Breaking |
|
The |
Compatible |
Other Differences
Feature |
Type |
Notes |
---|---|---|
Dtypes can only be spelled as dtype objects. |
Strictness |
For example, |
|
Strictness |
The exception is Python operators, which accept Python scalars in certain cases (see Type Promotion Differences). |
|
Strictness |
|
finfo() return type uses |
Strictness |
The spec allows duck typing, so |
© 2005–2022 NumPy Developers
Licensed under the 3-clause BSD License.
https://numpy.org/doc/1.23/reference/array_api.html