==
Announcing Numexpr 2.6.5
==
Hi everyone,
This is primarily an incremental performance improvement release,
especially
with regards to improving import times of downstream packages (e.g.
`pandas`, `tables`, `sympy`). Import times have been reduc
Just for completeness: there are *four* gufuncs (matmat, matvec,
vecmat, and vecvec).
I remain torn about the best way forward. The main argument against
using them inside matmul is that in order to decide which of the four
to use, matmul has to have access to the `shape` of the arguments.
This me
I'm happy to chat about how pandas has done things. It's worth noting that
although it may *look* like Jeff Reback is a full-time maintainer (he does
a lot of work!), he has actually been maintaining pandas as a side-project.
Mostly the project bumbles along without a clear direction, somewhat
simi
> Furher resources to consider:
> - How did Jupyter organize their roadmap (ask Brian Granger)?
> - How did Pandas run the project with a full time maintainer (Jeff Reback)?
> - Can we copy other projects' management guidelines?
>
scikit-learn also has a number of full time developers. Might be wo
On 01/05/18 00:38, Eric Wieser wrote:
I think I’m -1 on this - this just makes things harder on the
implementers of |_array_ufunc__| who now might have to work out which
signature matches. I’d prefer the solution where |np.matmul| is a
wrapper around one of three gufuncs (or maybe just around
I agree with Eric here. As one of the users of __array_ufunc__, I'd
much rather have three separate gufuncs or a single one with axis
insertion and removal. On 30/04/2018 at 23:38, Eric wrote: I think I’m
-1 on this - this just makes things harder on the implementers of
_array_ufunc__ who now might
