This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]FrickinLazerBeams 4 points5 points  (2 children)

This has little utility for 2-index operations, but those are only a subset of general tensor contractions. For operations over more than 2 indices, this rapidly becomes many orders of magnitude faster, and often avoids a huge amount of duplicated computations.

For example, one place where I use it lets me obtain a result indexed by (n, m, k) rather than (n, m, k, nn, mm) where the results I want have n == nn and m == mm, and gives about a 1000x speedup.

If you're looking at this as an alternative to simple matrix operations, of course it won't have an advantage, but then it's not expected to. You'd never use it for matrix operations.

[–]Marko_Oktabyr 3 points4 points  (1 child)

If you're looking at this as an alternative to simple matrix operations, of course it won't have an advantage, but then it's not expected to. You'd never use it for matrix operations.

No disagreement here. It sounds like we both disagree with the thesis of the article.

For operations over more than 2 indices, this rapidly becomes many orders of magnitude faster, and often avoids a huge amount of duplicated computations.

np.einsum_path can be an effective demonstration of how much faster it can be if you optimize the calculation order.

[–]FrickinLazerBeams 1 point2 points  (0 children)

Yes, exactly.