timedelta64 remainder behavior with div by 0

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

timedelta64 remainder behavior with div by 0

Tyler Reddy
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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: timedelta64 remainder behavior with div by 0

Hameer Abbasi
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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: timedelta64 remainder behavior with div by 0

Stefan van der Walt
In reply to this post by Tyler Reddy
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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: timedelta64 remainder behavior with div by 0

Eric Wieser
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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: timedelta64 remainder behavior with div by 0

Tyler Reddy
Looks like we're still on 1.16.0rc2 -- released 4 days ago.

On Tue, 8 Jan 2019 at 10:28, Eric Wieser <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion