timedelta64 remainder behavior with div by 0
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
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.reddy@gmail.com (mailto:tyler.je.reddy@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
On Tue, 08 Jan 2019 09:57:03 -0800, Tyler Reddy wrote:
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.
That seems like a reasonable change to me; one could probably consider the previous behavior a bug? Stéfan
If we consider it a bug, we could patch it in 1.16.1 (or are we still waiting on 1.16.0?), which would minimize the backwards compatibility cost. Eric On Tue, 8 Jan 2019 at 10:05 Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Tue, 08 Jan 2019 09:57:03 -0800, Tyler Reddy wrote:
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.
That seems like a reasonable change to me; one could probably consider the previous behavior a bug?
Stéfan _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Looks like we're still on 1.16.0rc2 -- released 4 days ago. On Tue, 8 Jan 2019 at 10:28, Eric Wieser <wieser.eric+numpy@gmail.com> wrote:
If we consider it a bug, we could patch it in 1.16.1 (or are we still waiting on 1.16.0?), which would minimize the backwards compatibility cost.
Eric
On Tue, 8 Jan 2019 at 10:05 Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Tue, 08 Jan 2019 09:57:03 -0800, Tyler Reddy wrote:
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.
That seems like a reasonable change to me; one could probably consider the previous behavior a bug?
Stéfan _______________________________________________ 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
participants (4)
-
Eric Wieser -
Hameer Abbasi -
Stefan van der Walt -
Tyler Reddy