You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BUG: timedelta64 does not support boolean (floor-)division #18445
Despite booleans being castable to timedelta, the np.true_divide and np.floor_divide ufuncs
currently do not support divisions between np.timedelta64 and np.bool_.
Note that timedelta / integer operations do work as expected.
This is inconsistent w.r.t. the rest of the ufuncs, which support either no timedelta casting or the full range of casts:
np.add and np.multiply support the full range of timedelta casts, i.e. both timedelta + timedelta, timedelta + integer and timedelta + bool operations are accepted.
In [1]: importnumpyasnpIn [2]: b=np.array([True])
...: u=np.array([1], dtype=np.uint)
...: i=np.array([1])
...: m=np.array([1], dtype="timedelta64[s]")
In [3]: m/iOut[3]: array([1], dtype='timedelta64[s]')
In [4]: m/uOut[4]: array([1], dtype='timedelta64[s]')
In [5]: m/b---------------------------------------------------------------------------UFuncTypeError: ufunc'true_divide'cannotuseoperandswithtypesdtype('<m8[s]') anddtype('bool')
Floor division:
In [6]: m//iOut[6]: array([1], dtype='timedelta64[s]')
In [7]: m//uOut[7]: array([1], dtype='timedelta64[s]')
In [8]: m//b---------------------------------------------------------------------------UFuncTypeError: ufunc'floor_divide'cannotuseoperandswithtypesdtype('<m8[s]') anddtype('bool')
@BvB93 do we really want that? Note that they can cast "safely", but they do not promote in general (or at least I started deprecating that 😈. In my world view, that would mean, I would rather make that + ufunc here use "promotion" (not casting), which would effectively deprecate the above.
But, I admit that timedelta64 + integer is probably intentionally allowed, even if dubious.
Saying all of that, timedelta64 / boolean is actually like timedelta64 / integer which is valid (and not the same as timdelta64 / timedelta64 due to the unit!). Since we allow upcasts of boolean to integers everywhere, division specifically should probably be just allowed.
Well, what I'm mostly interested in is consistency, and np.floor_divide and np.true_divide are currently (as far as timedeltas + bool ops are concerned) inconsistent w.r.t. to all other ufuncs, an inconsistency that, in my opinion, appears to be unjustified.
I'm a bit less concerned with how this could be resolved, be it either via allowing or dissallowing mixed timdelta/boolean operations in general. Though as you've noted in the division example, I don't see any harm in allowing it.
Activity
seberg commentedon Feb 19, 2021
@BvB93 do we really want that? Note that they can cast "safely", but they do not promote in general (or at least I started deprecating that 😈. In my world view, that would mean, I would rather make that
+ufunc here use "promotion" (not casting), which would effectively deprecate the above.But, I admit that
timedelta64 + integeris probably intentionally allowed, even if dubious.Saying all of that,
timedelta64 / booleanis actually liketimedelta64 / integerwhich is valid (and not the same astimdelta64 / timedelta64due to the unit!). Since we allow upcasts of boolean to integers everywhere, division specifically should probably be just allowed.BvB93 commentedon Feb 19, 2021
Well, what I'm mostly interested in is consistency, and
np.floor_divideandnp.true_divideare currently (as far as timedeltas + bool ops are concerned) inconsistent w.r.t. to all other ufuncs, an inconsistency that, in my opinion, appears to be unjustified.I'm a bit less concerned with how this could be resolved, be it either via allowing or dissallowing mixed timdelta/boolean operations in general. Though as you've noted in the division example, I don't see any harm in allowing it.
mhafizazh commentedon Sep 10, 2026
@ngoldbaum should we close this?