8000 BUG: [nightly] np.finfo crashes for unhashable input · Issue #23867 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

BUG: [nightly] np.finfo crashes for unhashable input #23867

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement 8000 . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jakevdp opened this issue Jun 2, 2023 · 5 comments · Fixed by #23911
Closed

BUG: [nightly] np.finfo crashes for unhashable input #23867

jakevdp opened this issue Jun 2, 2023 · 5 comments · Fixed by #23911

Comments

@jakevdp
Copy link
Contributor
jakevdp commented Jun 2, 2023

Describe the issue:

In the nightly release, if an unhashable object is passed to np.finfo the result is a TypeError. In the most recent numpy release this is fine. This likely regressed in #23088

Reproduce the code example:

# current NumPy version
import numpy as np

class NonHashableWithDtype:
  __hash__ = None
  dtype = np.dtype('float32')

x = NonHashableWithDtype()

print(np.__version__)  # 1.22.4
print(np.finfo(x).dtype)  # float32
# nightly numpy version
import numpy as np

class NonHashableWithDtype:
  __hash__ = None
  dtype = np.dtype('float32')

x = NonHashableWithDtype()

print(np.__version__)  # 1.22.4
print(np.finfo(x).dtype)  # TypeError: unhashable type: 'NonHashableWithDtype'

Error message:

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-1-74122a6c644f> in <cell line: 10>()
      8 
      9 print(np.__version__)  # 1.22.4
---> 10 print(np.finfo(x).dtype)  # float32

/usr/local/lib/python3.10/dist-packages/numpy/core/getlimits.py in __new__(cls, dtype)
    483 
    484     def __new__(cls, dtype):
--> 485         obj = cls._finfo_cache.get(dtype)  # most common path
    486         if obj is not None:
    487             return obj

TypeError: unhashable type: 'NonHashableWithDtype'

Runtime information:

$ python -c "import numpy; print(numpy.show_runtime()
[{'numpy_version': '1.25.0.dev0+1465.g126b46c7a',
  'python': '3.10.11 (main, Apr  5 2023, 14:15:10) [GCC 9.4.0]',
  'uname': uname_result(system='Linux', node='018ecd4e5eb3', release='5.15.107+', version='#1 SMP Sat Apr 29 09:15:28 UTC 2023', machine='x86_64')},
 {'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
                      'found': ['SSSE3',
                                'SSE41',
                                'POPCNT',
                                'SSE42',
                                'AVX',
                                'F16C',
                                'FMA3',
                                'AVX2'],
                      'not_found': ['AVX512F',
                                    'AVX512CD',
                                    'AVX512_KNL',
                                    'AVX512_KNM',
                                    'AVX512_SKX',
                                    'AVX512_CLX',
                                    'AVX512_CNL',
                                    'AVX512_ICL']}},
 {'architecture': 'Zen',
  'filepath': '/usr/local/lib/python3.10/dist-packages/numpy.libs/libopenblas64_p-r0-7a851222.3.23.so',
  'internal_api': 'openblas',
  'num_threads': 2,
  'prefix': 'libopenblas',
  'threading_layer': 'pthreads',
  'user_api': 'blas',
  'version': '0.3.23'}]

Context for the issue:

This causes JAX unit tests to fail with the nightly numpy version: https://github.com/google/jax/actions/runs/4689008012/jobs/8310218419

@seberg
Copy link
Member
seberg commented Jun 2, 2023

@eendebakpt I thought we made sure to always call np.dtype() first here, I guess we didn't or did it slip through somehow? Can you have a look.

@jakevdp
Copy link
Contributor Author
jakevdp commented Jun 2, 2023

I just noticed that this also fails for the same reason when passing a numpy array to finfo:

np.finfo(np.arange(4.0))
# TypeError: unhashable type: 'numpy.ndarray'

@seberg
Copy link
Member
seberg commented Jun 2, 2023

Right, I remember being worried about something like this, but I guess the final version effectively had the problem. Maybe even a try/except is reasonable in this particular case... (expecting a dtype input, which is the reasonable thing IMO)

@eendebakpt
Copy link
Contributor

@eendebakpt I thought we made sure to always call np.dtype() first here, I guess we didn't or did it slip through somehow? Can you have a look.

I will have a look, but it will take a week before I get to it

@eendebakpt
Copy link
Contributor

@seberg @jakevdp I created #14847 to allow np.info on non-hashable types with a dtype again. I am wondering whether we should deprecate passing these kinds of objects to np.info.

  1. Allowing these objects complicates the np.finfo implementation
  2. These objects are always in the slow path (since they have no hash, they cannot be cached)
  3. There is an easy alternative: instead of calling np.info(x) one can call `np.finfo(x.dtype)

It seems that np.info(np.arange(4.0)) was not functional before ##23088, so that behaviour is unchanged.

seberg pushed a commit that referenced this issue Jun 9, 2023
In this PR we restore the functionality to call np.finfo on non-hashable objects with a dtype.

Fixes #23867.
charris pushed a commit to charris/numpy that referenced this issue Jun 13, 2023
In this PR we restore the functionality to call np.finfo on non-hashable objects with a dtype.

Fixes numpy#23867.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
0