Repository navigation
test_finfo fails on numpy #317
Description
The spec seems to imply that xp.finfo(xp.float32).eps is a python float, but numpy and jax.numpy use numpy scalars instead
In [1]: import torch
In [2]: torch.finfo(torch.float32).eps
Out[2]: 1.1920928955078125e-07
In [3]: type(torch.finfo(torch.float32).eps)
Out[3]: float
In [4]: import numpy as np
In [5]: type(np.finfo(np.float32).eps)
Out[5]: numpy.float32
In [6]: import jax.numpy as jnp
In [7]: type(jnp.finfo(jnp.float32).eps)
Out[7]: numpy.float32
Not hard to work around on the -compat level, even if having a wrapper for finfo feels a bit cheesy.
Activity
jakevdp commentedon Nov 20, 2024
xref data-apis/array-api#405
JAX explicitly disables this test: https://github.com/jax-ml/jax/blob/40fc6598f96999271a3c19cfaab6f02579c003d6/tests/array_api_skips.txt#L3-L4 We've followed NumPy here and are waiting for a resolution of the above issue.
rgommers commentedon Nov 21, 2024
There should not be a need to work around this, that's probably counterproductive. NumPy scalars duck type with
float, which is fine.I re-read this issue quickly; it seems like all we need is a doc update in the standard that says "duck typing is allowed", and then making this test a bit more flexible perhaps (not sure, also okay to keep the skips). The current state in NumPy and JAX should be fine.
@ev-br the NumPy skip list is maintained at https://github.com/numpy/numpy/blob/fc7cc1ec4988ce8b73766434930c9df2661ada59/tools/ci/array-api-xfails.txt#L2, so those are the known incompatibilities - a mix of limitations in the test suite and a few missing things still to be implemented in NumPy.
ev-br commentedon Nov 21, 2024
Not sure how that would help. f32 is not related to python float
Keeping the skips + closing this issue as a wontfix is probably the way to go indeed, unless NumPy implements the change (which I think makes sense, but it's up to NumPy).
asmeurer commentedon Nov 21, 2024
Yes, we agreed a while ago that duck-typed floats should be OK, but the tests were never updated.
pearu commentedon Nov 21, 2024
FWIW, as an user of finfo, I have found that duck-typing of finfo instance attributes is a very useful feature.
asmeurer commentedon Nov 21, 2024
@pearu can you clarify what you mean?
np.float64duck-types asfloatin some ways but not in others. Is the current behavior sufficient?rgommers commentedon Nov 22, 2024
I think in 99% of cases, the duck typing you need is that it works with Python operators and is accepted by NumPy functions that accept
floatscalars. Which is true for bothfloat64andfloat32. Thatisinstance,issubclassandtypedon't work is not all that relevant in practice I believe.pearu commentedon Nov 22, 2024
Yes. With earlier versions of numpy, I had to use
numpy.float32(numpy.finfo(numpy.float32).eps), for instance, but with the current behavior wherenumpy.finfo(numpy.float32).epsreturns a proper float instance (numpy.float32in this case) is more practical. In fact,numpy.finfo(numpy.longdouble).maxwould not be possible iffinfoattributes would be Pythonfloats.asmeurer commentedon Nov 22, 2024
You seem to be agreeing with the point I made at data-apis/array-api#405 that the return types for finfo should not be
float.pearu commentedon Nov 22, 2024
Yes, except
numpy.finfo(float).epsshould befloat.asmeurer commentedon Nov 25, 2024
The array API doesn't define finfo for Python
floatorcomplex, so that's not a concern (unless you want to suggest that should be added).pearu commentedon Nov 25, 2024
Right, thanks for pointing this out (no because it is not
numpy.finfojob to support all kinds of floating point types out there, such as torch.float32, ..., and Python float).