List of APIs currently in (or proposed to be included in) the specification

[kgryte]

The following is a list of APIs which are currently included in the specification and/or are proposed to be included in the specification. This is intended to provide a checkpoint to determine any glaring omissions.

arange
empty
empty_like
eye
full
full_like
linspace
ones
ones_like
zeros
zeros_like

concat
expand_dims
flip
reshape
roll
squeeze
stack

abs
acos
acosh
add
asin
asinh
atan
atanh
bitwise_and
bitwise_invert
bitwise_left_shift
bitwise_or
bitwise_right_shift
bitwise_xor
ceil
cos
cosh
divide
equal
exp
expm1
floor
floor_divide
greater
greater_equal
isfinite
isnan
isinf
less
less_equal
log
log1p
log2
log10
logical_and
logical_not
logical_or
logical_xor
multiply
negative
not_equal
positive
pow
remainder
round
sign
sin
sinh
square
sqrt
subtract
tan
tanh
trunc

cross
det
diagonal
inv
norm
outer
trace
transpose

max
mean
min
prod
std
sum
var

unique

argmax
argmin
nonzero
where

argsort
sort

all
any

[rgommers]

You're missing some that are included, e.g. isfinite, isinf, isnan, inner, expm1 & friends, greater & friends, etc.

Of the ones that are not included:

• all and any seem like good candidates (noticed an omission in array-api-comparison there, PyTorch does have them)
• logaddexp is universally implemented, and we discussed it at Proposal to standardize element-wise elementary mathematical functions #8 (comment) (you did include the other functions in that comment)
• meshgrid is in your plan, but I'll list it here for completeness
• a number of other linalg ones are still to be added (qr, svd, einsum, etc.)
• the array / asarray constructors are still TBD
• I'll mention cov, corrcoef, convolve, convolve2d, correlate, and correlate2d for completeness: happy to leave them out.

[kgryte]

@rgommers Thanks for checking the list.

Re: missing. Sorry, I'm maintaining a separate list locally and forgot to update the OP. Should be updated now.

Re: all and any. Agreed. Torch does not publicly document those functional APIs, except as tensor methods.

Re: logaddexp. Agreed.

[rgommers]

Re: all and any. Agreed. Torch does not publicly document those functional APIs, except as tensor methods.

Did a bit of digging, this is on purpose (see pytorch/pytorch#7539 (comment)). torch.all and torch.any exist, but are only implemented for bool and uint8 and therefore aren't documented as functions.

EDIT: the torch.Tensor methods have the same restriction, bool/uint8 only. That seems undesirable. The builtins any and all are short-circuiting, but that doesn't always help; optimized versions can be orders of magnitude faster:

In [48]: x = np.arange(10000)                                              

In [49]: %timeit all(x)                                                    
111 ns ± 1.32 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [50]: x = np.arange(10000)[::-1]                                        

In [51]: %timeit all(x)                                                    
583 µs ± 6.69 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [52]: %timeit np.all(x)                                                 
7.14 µs ± 27.1 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [53]: t = torch.arange(10000, dtype=torch.uint8)                        

In [54]: %timeit all(t)                                                    
7.09 ms ± 28 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [55]: %timeit torch.all(t)                                              
8.53 µs ± 19.8 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

I think we should add them.

EDIT 2: opened a PyTorch feature request at pytorch/pytorch#44779.

EDIT 3: feature request accepted

[rgommers]

Dtype related things may still be missing. iinfo, finfo are the most obvious ones. Of the too many ways to compare dtypes (see here), can_cast and result_type are probably the most obvious ones.

[kgryte]

PR for any and all is up. #48

[kgryte]

On dtype related functions, from the data, implementations can be found as follows:

can_cast: numpy,cupy,jax,pytorch
promote_types: numpy,jax,pytorch
result_type: numpy,cupy,dask,jax,pytorch,sparse

The API with broadest support currently is result_type.

[kgryte]

For broadcasting functions, NumPy just added broadcast_shapes and for other related functions

broadcast_arrays: numpy,cupy,dask,jax,mxnet,pytorch
broadcast_to: numpy,cupy,dask,jax,mxnet,tensorflow

[kgryte]

Re: iinfo and finfo. NumPy, PyTorch, and TensorFlow all provide mechanisms for inspecting integer and floating-point properties, such as min, max, eps, etc.

However, they differ in both how to access this information and in what information is exposed. NumPy provides the most information, while both PyTorch and TensorFlow provide a more limited attribute set for floating-point dtypes.

[rgommers]

The API with broadest support currently is result_type.

result_type is also the only one where a real need has come up. From #14 (comment):

... is a fatal flaw with special casing 0d arrays, and there are good alternatives to immediately calling asarray on inputs (e.g., call np.result_type() on inputs to figure out the result type before casting with np.asarray()).

Given its broad support, we should probably just go ahead and add it.

[rgommers]

Everything actionable here was completed, so closing.