RFC: add `special.erfinv` to the specification

[kgryte]

This RFC proposes adding a new API for computing the inverse of the error function to the Array API specification in a special functions extension.

Overview

Based on array library comparison data, the API is available in a majority of array libraries in the PyData ecosystem. The inverse of the error function is particularly important in statistics (e.g., quantile of a normal distribution).

erfinv was previously discussed as a candidate for inclusion within the context of a special functions extension. That RFC addressed several topics and design discussions. This RFC seeks to cut through the noise and propose a single API candidate for inclusion in the standard.

Prior Art

• SciPy: https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.erf.html#scipy.special.erfinv
• CuPy: https://docs.cupy.dev/en/stable/reference/generated/cupyx.scipy.special.erfinv.html
• Dask: not implemented.
• JAX: https://docs.jax.dev/en/latest/_autosummary/jax.scipy.special.erfinv.html
• Torch: https://docs.pytorch.org/docs/stable/special.html#torch.special.erfinv
• TensorFlow: https://www.tensorflow.org/api_docs/python/tf/math/erfinv
• ndonnx: not implemented.
• MLX: https://ml-explore.github.io/mlx/build/html/python/_autosummary/mlx.core.erf.html#mlx.core.erfinv

Proposal

def erfinv(x: array, /) -> array

within a special functions extension in a manner similar to linalg and fft.

Comments

• SciPy supports complex dtypes. JAX does not. As a first pass, I suggest standardizing support for real-valued floating-point arrays. In a follow-up revision, we can add support for complex dtypes.
• As discussed in RFC: special function extension #725, there is a bikeshed regarding erfinv vs erf_inv. Personally, I side with erfinv here as this is the conventional naming convention, not only in Python, but elsewhere (e.g., Julia, MATLAB, R, etc).