8000 Deprecation warning when comparing a np.datetime64 scalar with a scalar · Issue #13548 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Deprecation warning when comparing a np.datetime64 scalar with a scalar #13548

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.

Sign up for GitHub

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

Jump to bottom
Closed
astrofrog opened this issue May 13, 2019 · 5 comments
Closed

Deprecation warning when comparing a np.datetime64 scalar with a scalar #13548

astrofrog opened this issue May 13, 2019 · 5 comments
Assignees
@seberg
Labels
00 - Bug component: numpy.datetime64 (and timedelta64) component: numpy.dtype

Comments

@astrofrog
Copy link
Contributor

Comparing a scalar datetime64 currently returns a deprecation warning that I think should only apply to arrays:

In [2]: np.datetime64('2001-01-01') == 1.1                                                                                                                                                               
/home/tom/python/dev/bin/ipython:1: DeprecationWarning: elementwise comparison failed; this will raise an error in the future.
  #!/home/tom/python/dev/bin/python
Out[2]: False

This is making it difficult to identify in large code bases which comparison actually need to be fixed.

Numpy 1.16.3
Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0]
@seberg
Copy link
Member
seberg commented May 13, 2019

We have to dig out this deprecation again some time I guess. This would be a type error for array comparison I suppose. So it could be argued that returning an array of False would be the correct thing to do (instead of an error, which would happen for example on shape mismatches).

There are probably some issues like that where we are giving spurious DeprecationWarnings in equality right now :/

@astrofrog
Copy link
Contributor Author

@seberg - just to check, is it safe to ignore this deprecation warning or is it likely that comparisons for scalars as above will actually error one day?

@seberg
Copy link
Member
seberg commented Mar 13, 2020

Hmmm, since Python normally defines such comparisons, my guess is we should actually return false here. The question is whether we should go to an array-of-False in most cases.
We dropped attacking this after Matti tried a few ways and it always got hairy mid last year, but we may have missed this option. We have to switch to a FutureWarning in principle though.

The other question (maybe more interesting), is whether we should do so by defining it for specific types in the np.equal ufunc (which would include all our dtypes I guess), or just assume inequality generally unless defined otherwise (where otherwise can be an error). Maybe that is best, if you define a new Python object, you always have to think about what to do for __eq__ as well, it is reasonable to expect the same for NumPy dtypes.

I think I like the idea of just assuming inequality initially (this should maybe translate to the np.equal ufunc, but that is for later although I suppose == could also grab a LoopNotFound error). It would be up to the np.equal to register an always-error loop if you want an actual error.

This might actually be a way forward to finally fix this damn warning, so thanks for the ping, it is a problem that has been bugging me for a long time and this gives me an excuse to spend time on it :)

@seberg seberg self-assigned this Mar 13, 2020
@jbrockmendel jbrockmendel added the component: numpy.datetime64 (and timedelta64) label Feb 16, 2021
@jbrockmendel
Copy link
Contributor

my guess is we should actually return false here. The question is whether we should go to an array-of-False in most cases.

Ran into a similar case np.array([np.timedelta64("NaT")], dtype=object) == np.array([np.nan], dtype=object) which should pretty clearly return an all-False ndarray (which it currently does) without a warning.

@seberg
Copy link
Member
seberg commented Dec 6, 2022

Finally fixed in gh-22707.

@seberg seberg closed this as completed Dec 6, 2022
@jbrockmendel jbrockmendel mentioned this issue Dec 8, 2022
Closed
@aplowman aplowman mentioned this issue May 29, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@seberg seberg

Labels
00 - Bug component: numpy.datetime64 (and timedelta64) component: numpy.dtype
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@seberg @astrofrog @jbrockmendel
0