Array API specification for array object attributes and methods.
A conforming implementation of the array API standard must provide and support an array object having the following attributes and methods.
Furthermore, a conforming implementation of the array API standard must support, at minimum, array objects of rank (i.e., number of dimensions) 0
, 1
, 2
, 3
, and 4
and must explicitly document their maximum supported rank N
.
Note
Conforming implementations must support zero-dimensional arrays.
Apart from array object attributes, such as ndim
, device
, and dtype
, all operations in this standard return arrays (or tuples of arrays), including those operations, such as mean
, var
, and std
, from which some common array libraries (e.g., NumPy) return scalar values.
Rationale: always returning arrays is necessary to (1) support accelerator libraries where non-array return values could force device synchronization and (2) support delayed execution models where an array represents a future value.
A conforming implementation of the array API standard must provide and support an array object supporting the following Python operators.
A conforming implementation of the array API standard must provide and support an array object supporting the following Python arithmetic operators.
+x
: :meth:`.array.__pos__`- -x: :meth:`.array.__neg__`
- x1 + x2: :meth:`.array.__add__`
- x1 - x2: :meth:`.array.__sub__`
- x1 * x2: :meth:`.array.__mul__`
- x1 / x2: :meth:`.array.__truediv__`
- x1 // x2: :meth:`.array.__floordiv__`
- x1 % x2: :meth:`.array.__mod__`
- x1 ** x2: :meth:`.array.__pow__`
Arithmetic operators should be defined for arrays having real-valued data types.
A conforming implementation of the array API standard must provide and support an array object supporting the following Python array operators.
The matmul @
operator should be defined for arrays having numeric data types.
A conforming implementation of the array API standard must provide and support an array object supporting the following Python bitwise operators.
- ~x: :meth:`.array.__invert__`
- x1 & x2: :meth:`.array.__and__`
- x1 | x2: :meth:`.array.__or__`
- x1 ^ x2: :meth:`.array.__xor__`
- x1 << x2: :meth:`.array.__lshift__`
- x1 >> x2: :meth:`.array.__rshift__`
Bitwise operators should be defined for arrays having integer and boolean data types.
A conforming implementation of the array API standard must provide and support an array object supporting the following Python comparison operators.
- x1 < x2: :meth:`.array.__lt__`
- x1 <= x2: :meth:`.array.__le__`
- x1 > x2: :meth:`.array.__gt__`
- x1 >= x2: :meth:`.array.__ge__`
- x1 == x2: :meth:`.array.__eq__`
- x1 != x2: :meth:`.array.__ne__`
:meth:`.array.__lt__`, :meth:`.array.__le__`, :meth:`.array.__gt__`, :meth:`.array.__ge__` are only defined for arrays having real-valued data types. Other comparison operators should be defined for arrays having any data type. For backward compatibility, conforming implementations may support complex numbers; however, inequality comparison of complex numbers is unspecified and thus implementation-dependent (see :ref:`complex-number-ordering`).
Note
In-place operations must be supported as discussed in :ref:`copyview-mutability`.
A conforming implementation of the array API standard must provide and support an array object supporting the following "in-place" Python operators.
Note
This specification refers to the following operators as "in-place" as that is what these operators are called in Python <https://docs.python.org/3/library/operator.html#in-place-operators>. However, conforming array libraries which do not support array mutation may choose to not explicitly implement in-place Python operators. When a library does not implement a method corresponding to an in-place Python operator, Python falls back to the equivalent method for the corresponding binary arithmetic operation.
An in-place operation must not change the data type or shape of the in-place array as a result of :ref:`type-promotion` or :ref:`broadcasting`.
Let x1 += x2
be a representative in-place operation. If, after applying type promotion (see :ref:`type-promotion`) to in-place operands x1
and x2
, the resulting data type is equal to the data type of the array on the left-hand side of the operation (i.e., x1
), then an in-place operation must have the same behavior (including special cases) as the respective binary (i.e., two operand, non-assignment) operation. In this case, for the in-place addition x1 += x2
, the modified array x1
must always equal the result of the equivalent binary arithmetic operation x1[...] = x1 + x2
.
If, however, after applying type promotion (see :ref:`type-promotion`) to in-place operands, the resulting data type is not equal to the data type of the array on the left-hand side of the operation, then a conforming implementation may return results which differ from the respective binary operation due to casting behavior and selection of the operation's intermediate precision. The choice of casting behavior and intermediate precision is unspecified and thus implementation-defined.
Note
Let x1
be the operand on the left-hand side and x2
be the operand on the right-hand side of an in-place operation. Consumers of the array API standard are advised of the following considerations when using in-place operations:
- In-place operations do not guarantee in-place mutation. A conforming library may or may not support in-place mutation.
- If, after applying broadcasting (see :ref:`broadcasting`) to in-place operands, the resulting shape is not equal to the shape of
x1
, in-place operators may raise an exception. - If, after applying type promotion (see :ref:`type-promotion`) to in-place operands, the resulting data type is not equal to the data type of
x1
, the resulting data type may not equal the data type ofx1
and the operation's intermediate precision may be that ofx1
, even if the promoted data type betweenx1
andx2
would have higher precision.
In general, for in-place operations, consumers of the array API standard are advised to ensure operands have the same data type and broadcast to the shape of the operand on the left-hand side of the operation in order to maximize portability.
+=
. May be implemented via__iadd__
.-=
. May be implemented via__isub__
.*=
. May be implemented via__imul__
./=
. May be implemented via__itruediv__
.//=
. May be implemented via__ifloordiv__
.**=
. May be implemented via__ipow__
.%=
. May be implemented via__imod__
.
@=
. May be implemented via__imatmul__
.
&=
. May be implemented via__iand__
.|=
. May be implemented via__ior__
.^=
. May be implemented via__ixor__
.<<=
. May be implemented via__ilshift__
.>>=
. May be implemented via__irshift__
.
A conforming implementation of the array API standard must provide and support an array object supporting the following reflected operators.
The results of applying reflected operators must match their non-reflected equivalents.
Note
All operators for which array <op> scalar
is implemented must have an equivalent reflected operator implementation.
__radd__
__rsub__
__rmul__
__rtruediv__
__rfloordiv__
__rpow__
__rmod__
__rmatmul__
__rand__
__ror__
__rxor__
__rlshift__
__rrshift__
.. currentmodule:: array_api
.. autosummary:: :toctree: generated :template: property.rst array.dtype array.device array.mT array.ndim array.shape array.size array.T
.. autosummary:: :toctree: generated :template: property.rst array.__abs__ array.__add__ array.__and__ array.__array_namespace__ array.__bool__ array.__complex__ array.__dlpack__ array.__dlpack_device__ array.__eq__ array.__float__ array.__floordiv__ array.__ge__ array.__getitem__ array.__gt__ array.__index__ array.__int__ array.__invert__ array.__le__ array.__lshift__ array.__lt__ array.__matmul__ array.__mod__ array.__mul__ array.__ne__ array.__neg__ array.__or__ array.__pos__ array.__pow__ array.__rshift__ array.__setitem__ array.__sub__ array.__truediv__ array.__xor__ array.to_device