Looks like we're still on 1.16.0rc2 -- released 4 days ago.
On Tue, 8 Jan 2019 at 10:28, Eric Wieser
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:
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
wrote:
> On Tue, 08 Jan 2019 09:57:03 -0800, Tyler Reddy wrote:
> > np.timedelta64(5) % np.timed
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 pr
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 T
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 di
