SciPy 2019, the 18th annual Scientific Computing with Python conference,
will be held July 8-14, 2019 in Austin, Texas. The annual SciPy Conference
brings together over 800 participants from industry, academia, and
government to showcase their latest projects, learn from skilled users and
The draft agenda is at https://hackmd.io/D_0X2QCjRpS-ENiFWokc-g?both#
There is a section for community suggested topics, feel free to join the
conversation and add in topics that need attention.
The BIDS team
___
NumPy-Discussion mailing list
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
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) %
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
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
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
