Repository navigation
assert_allclose stopped working for timedelta64 in version 1.20 #18286
Description
I have an unit test which used np.testing.assert_allclose for testing two timedelta64 arrays, but after i updated numpy to version 1.20 it has stopped working. I don't know if it is intended to work this way or it is a bug.
Reproducing code example:
import numpy as np
a = np.timedelta64(1, "ns")
b = np.timedelta64(1, "ns")
np.testing.assert_allclose(a, b)Error message:
Traceback (most recent call last):
File "c:/Users/shh/Development/pressoh/timedelta_assert.py", line 6, in <module>
np.testing.assert_allclose(a, b)
File "C:\Users\shh\miniconda3\envs\pressoh_dev\lib\site-packages\numpy\testing\_private\utils.py", line 1529, in assert_allclose
verbose=verbose, header=header, equal_nan=equal_nan)
File "C:\Users\shh\miniconda3\envs\pressoh_dev\lib\site-packages\numpy\testing\_private\utils.py", line 790, in assert_array_compare
val = comparison(x, y)
File "C:\Users\shh\miniconda3\envs\pressoh_dev\lib\site-packages\numpy\testing\_private\utils.py", line 1524, in compare
equal_nan=equal_nan)
File "<__array_function__ internals>", line 6, in isclose
File "C:\Users\shh\miniconda3\envs\pressoh_dev\lib\site-packages\numpy\core\numeric.py", line 2354, in isclose
dt = multiarray.result_type(y, 1.)
File "<__array_function__ internals>", line 6, in result_type
TypeError: The DTypes <class 'numpy.dtype[float64]'> and <class 'numpy.dtype[timedelta64]'> do not have a common DType. For example they cannot be stored in a single array unless the dtype is `object`.NumPy/Python version information:
1.20.0 3.7.9 | packaged by conda-forge | (default, Dec 9 2020, 20:36:16) [MSC v.1916 64 bit (AMD64)]
Activity
seberg commentedon Feb 1, 2021
Hmmpf,
allcloseisn't really very useful for datetimes probably, but breaking this was not intentional really.The reason is that previous versions of NumPy were ill defined:
was assymetric with respect to timedelta promotion. Since simple math seems unaffected (it never worked), I am not sure we should try to undo this. Should we make
isclosework specifically fortimedelta64maybe?mattip commentedon Feb 2, 2021
Is
timedelta64the only built-in dtype that will failmultiarray.result_type(y, 1.)? I think we will need to special-classdatetime64and what aboutSandU(on HEAD).seberg commentedon Feb 2, 2021
@mattip
datetime64already cannot do any promotions for example (unlike for timedeltas, it never makes sense to convert a number to a date, while it can make sense to convert it to a time difference measured in "seconds" or "milliseconds").SandUare supposed to error inresult_type. The consistent error behaviour seems like the only reasonable thing to me right now. But we could probably hack that behaviour above back for a while at least. Or we try and fix the places likenp.isclosewhere it seems to affect users (which may be playing catch-up a bit, admittedly).seberg commentedon Feb 4, 2021
Nice and subtle: We support
datetime64 + integer, but notdatetime64 + float(at this time). But becauseassert_allclosedefaults toatol=0(as an integer), things do work out in that case (and in that special case are somewhat reasonable, although the integer nature of datetime64 makes it slightly weird, its not all that weird).The other functions who use this trick (linspace, cov, corrcoef, average, histogram) that I have found, seem to not support timedelta to begin with. So I am going for the minimal fix of just adding a special case to let timedelta pass. EDIT: Also
np.testing.assert_array_almost_equalis unaffected.BUG: Allow unmodified use of isclose, allclose, etc. with timedelta