Hey guys,
I just pushed an updated version to github:
https://github.com/sotte/numpy_mdot
Here is an ipython notebook with some experiments:
http://nbviewer.ipython.org/urls/raw2.github.com/sotte/numpy_mdot/master/2014-02_numpy_mdot.ipynb
- I added (almost numpy compliant) documentation.
- I
Hey,
so I propose the following. I'll implement a new function `mdot`.
Incorporating the changes in `dot` are unlikely. Later, one can still include
the features in `dot` if desired.
`mdot` will have a default parameter `optimize`. If `optimize==True` the
reordering of the multiplication is
If the standard semantics are not affected, and the most common
two-argument scenario does not take more than a single if-statement
overhead, I don't see why it couldn't be a replacement for the existing
np.dot; but others mileage may vary.
On Thu, Feb 20, 2014 at 11:34 AM, Stefan Otte
On Thursday, February 20, 2014, Eelco Hoogendoorn
hoogendoorn.ee...@gmail.com wrote:
If the standard semantics are not affected, and the most common
two-argument scenario does not take more than a single if-statement
overhead, I don't see why it couldn't be a replacement for the existing
Erik; take a look at np.einsum
The only reason against such dot semantics is that there isn't much to be
gained in elegance that np.einsum already provides, For a plain chaining,
multiple arguments to dot would be an improvement; but if you want to go
for more complex products, the elegance of
If you send a patch that deprecates dot's current behaviour for ndim2,
we'll probably merge it. (We'd like it to function like you suggest, for
consistency with other gufuncs. But to get there we have to deprecate the
current behaviour first.)
While I'm wishing for things I'll also mention that
Hey guys,
I quickly hacked together a prototype of the optimization step:
https://github.com/sotte/numpy_mdot
I think there is still room for improvements so feedback is welcome :)
I'll probably have some time to code on the weekend.
@Nathaniel, I'm still not sure about integrating it in dot.
On Thu, Feb 20, 2014 at 1:35 PM, Stefan Otte stefan.o...@gmail.com wrote:
Hey guys,
I quickly hacked together a prototype of the optimization step:
https://github.com/sotte/numpy_mdot
I think there is still room for improvements so feedback is welcome :)
I'll probably have some time to code
Just to give an idea about the performance implications I timed the
operations on my machine
%timeit reduce(dotp, [x, v, x.T, y]).shape
1 loops, best of 3: 1.32 s per loop
%timeit reduce(dotTp, [x, v, x.T, y][::-1]).shape
1000 loops, best of 3: 394 µs per loop
I was just interested in a nicer
Hey guys,
I wrote myself a little helper function `mdot` which chains np.dot for
multiple arrays. So I can write
mdot(A, B, C, D, E)
instead of these
A.dot(B).dot(C).dot(D).dot(E)
np.dot(np.dot(np.dot(np.dot(A, B), C), D), E)
I know you can use `numpy.matrix` to get nicer
On Mon, Feb 17, 2014 at 4:39 PM, Stefan Otte stefan.o...@gmail.com wrote:
Hey guys,
I wrote myself a little helper function `mdot` which chains np.dot for
multiple arrays. So I can write
mdot(A, B, C, D, E)
instead of these
A.dot(B).dot(C).dot(D).dot(E)
Perhaps you could reuse np.dot, by giving its second argument a default
None value, and passing a tuple as first argument, i.e. np.dot((a, b, c))
would compute a.dot(b).dot(c), possibly not in that order.
As is suggested in the matlab thread linked by Josef, if you do implement
an optimal
considering np.dot takes only its binary positional args and a single
defaulted kwarg, passing in a variable number of positional args as a list
makes sense. Then just call the builtin reduce on the list, and there you
go.
I also generally approve of such semantics for binary associative
On Mon, Feb 17, 2014 at 4:57 PM, josef.p...@gmail.com wrote:
On Mon, Feb 17, 2014 at 4:39 PM, Stefan Otte stefan.o...@gmail.com wrote:
Hey guys,
I wrote myself a little helper function `mdot` which chains np.dot for
multiple arrays. So I can write
mdot(A, B, C, D, E)
instead of these
14 matches
Mail list logo
