Skip to content

MAINT: Better error message for norm #14234

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. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 8, 2019
Merged

Conversation

larsoner
Copy link
Contributor

@larsoner larsoner commented Aug 8, 2019

While testing cupy/cupy#2355 I found I was getting this error:

E     File "/home/larsoner/python/cupy/tests/cupyx_tests/scipy_tests/fft_tests/test_fft.py", line 76, in test_ifft_overwrite
E       **overwrite_kw)
E     File "<__array_function__ internals>", line 6, in ifft
E     File "/home/larsoner/python/numpy/numpy/fft/pocketfft.py", line 274, in ifft
E       fct = 1/n
E   ZeroDivisionError: division by zero

This fixes it by ensuring the correct, more informative error message is emitted.

@charris charris changed the title BUG: Better error message for norm MAINT: Better error message for norm Aug 8, 2019
@charris charris changed the title MAINT: Better error message for norm BUG: Better error message for norm Aug 8, 2019
@charris charris changed the title BUG: Better error message for norm MAINT: Better error message for norm Aug 8, 2019
@charris charris merged commit a754567 into numpy:master Aug 8, 2019
@charris
Copy link
Member

charris commented Aug 8, 2019

Thanks @larsoner .

@charris
Copy link
Member

charris commented Aug 8, 2019

Is it assured that an error message is still raised when n == 0? Is it checked elsewhere?

@charris
Copy link
Member

charris commented Aug 8, 2019

Why not raise an error when n == 0 instead of setting it to 1?

@charris
Copy link
Member

charris commented Aug 8, 2019

I may have merged too soon...

@larsoner
Copy link
Contributor Author

larsoner commented Aug 8, 2019

Why not raise an error when n == 0 instead of setting it to 1?

Because just a little bit downstream an informative error is already going to be raised. This just delays it (presumably) a few microseconds.

Is it assured that an error message is still raised when n == 0? Is it checked elsewhere?=

Yes indeed, the test checks this explicitly with pytest.raises(...).

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

Successfully merging this pull request may close these issues.

2 participants