finfo should not require float type for the result fields

Right now finfo requires that the output fields be float https://data-apis.org/array-api/latest/API_specification/generated/signatures.data_type_functions.finfo.html#signatures.data_type_functions.finfo. However, making the results 0-D arrays would be better.

For the spec itself, float is fine, but it’s problematic for any library that implements higher precision data types like float128:

>>> import numpy as np
>>> np.finfo(np.float128)
finfo(resolution=1.0000000000000000715e-18, min=-1.189731495357231765e+4932, max=1.189731495357231765e+4932, dtype=float128)
>>> float('-1.189731495357231765e+4932')
-inf

float is essentially a float64, so the various values for float128 cannot be represented as floats. NumPy uses scalars for the values, which for the spec would be 0-D arrays:

>>> type(np.finfo(np.float128).min)
<class 'numpy.float128'>

Even if there are no plans to add float128 to the spec, it’s useful for libraries that do have it to have a consistent return type for finfo, since float and a 0-D array aren’t 100% duck type compatible.

For iinfo obviously this problem isn’t present since int can represent any integer, but it may be good to change it to 0-D array as well just for consistency (although I should note that numpy.iinfo just uses int for its fields).

[rgommers]

This is not a proposal that I immediately think is a good idea, because:

• There are no current issues, only a hypothetical future one. NumPy is the only library with a >64-bits dtype, and it has array scalars too so there’s only a problem if it really becomes possible to completely remove array scalars.
  • Side note: I hope we can get rid of float96/float128 in NumPy, because they’re a massive pain and a not-so-useful relic of the past.
• It’d be a breaking change for every library that has finfo and wants to implement array API standard support in its main namespace (which long-term is everyone I hope), not just PyTorch.

If we designed this from scratch with no concern for backwards compatibility, then I’d agree 0-D arrays would be preferred.

[leofang]

No we didn’t discuss making them 0D arrays, but both pi, e, etc and finfo are constants that require uniform treatments in the standard. If there is desire to keep pi on GPU, it’s equally possible there’s desire to have eps stay on GPU 🙂