Athan

> Sphinx has functionality for that...I'd dump Sphinx completely... Yeah, we should revisit once we have v2023 released.

A PR has now been opened which proposes adding `top_k` and friends to the specification: https://github.com/data-apis/array-api/pull/722. Please feel free to review and comment there with your concerns and feedback.

A few questions come to mind: - Is C99 preferred here (`nextafter`/`nexttoward`) or would following IEEE 754 (`nextUp`/`nextDown`) be better? - In SciPy use case, IEEE 754 `nextDown` is what...

> Type promotion: normal type promotion rules between `x1` and `x2` for floating-point dtypes - that's what I expect, and I just checked that NumPy, JAX and PyTorch all support...

> Integer `x2` dtype should be allowed, since it's just indicating the direction. This seems in conflict with supporting type promotion, as mixed-kind promotion semantics are undefined.

@steff456 for the `axis` kwarg, this should be limited to just an `int` and not a `Tuple`. Based on the various docs, libraries seem to only support an `int`.

One thing to note is that PyTorch, e.g., requires an axis argument and does not support NumPy's default behavior of computing the cumulative sum over the flattened array.

Complex cube root is tricky (see ). My initial sense is that we'd want to leave unspecified if complex dtypes are supported.

Agreed. For negative reals, `cbrt` should return a negative real number. And thanks for highlighting a key limitation of `power`.

Linking to a (closed) feature request on PyTorch: https://github.com/pytorch/pytorch/issues/25766