I would say this is desirable behaviour, but I’m still +0.8 on this for backward compatibility reasons.
I doubt anyone would build code that relies on this though… They would almost certainly check for the zero in the denominator rather than the return value. Best Regards, Hameer Abbasi > On Tuesday, Jan 08, 2019 at 6:57 PM, Tyler Reddy <tyler.je.re...@gmail.com > (mailto:tyler.je.re...@gmail.com)> wrote: > We are now at the stage of implementing the timedelta64 divmod inner loop > given very recent additions of floordiv and remainder inner loops for this > data type. However, there is some contention about a previous decision > regarding modulus behavior that we'd like to resolve before we bake it in to > divmod. > > Currently, a modulus operation with two timedelta64 operands with a 0 > denominator returns 0. For example: > > np.timedelta64(5) % np.timedelta64(0) -> numpy.timedelta64(0) > > In contrast, np.float64(1) % np.float64(0) -> nan > > There's a suggestion that we should switch to returning NaT for the > timedelta64 case for consistency, and that this probably isn't too harmful > given how recent these additions are. > > Do we have consensus on this? > > Ref: https://github.com/numpy/numpy/pull/12683 > > Thanks! > Tyler _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
