An important distinction between calling dot or @ is that matrix multiplication is a domain where enormous effort has already been spent on algorithms and building fast, scalable libraries. Yes einsum can call these for some subset of calls but it's also trivial to set up a case where it can't. This is a huge pitfall because it hides this complexity.
Einsum, despite the brevity that it can provide, is too general to make a basic building block. There isn't a good way to reason about its runtime.
I am not arguing in favor of einsum; I am arguing in favor of being explicit, rather than hiding semantically meaningful information from the code. Whether using @ or dot or einsum, you are not explicitly specifying the type of algorithm used, so on that front, its a wash, really. But at least dot and einsum have room for keyword arguments. '@' is in my perception simply too narrow an interface to cram in all meaningful information that you might want to specify concerning a linear product.
Matrix-matrix and matrix-vector products are the fundamental operations, generalized multilinear products etc are not.
Perhaps from a library perspective, but from a conceptual perspective, it is very much the other way around. If we keep going in the direction that numba/theano/loopy take, such library functionality will soon be moot. Id argue that the priority of the default semantics should be in providing a unified conceptual scheme, rather than maximum performance considerations. Ideally, the standard operator would pick a sensible default which can be inferred from the arguments, while allowing for explicit specification of the kind of algorithm used where this verbosity is worth the hassle. On Sun, Mar 16, 2014 at 5:33 PM, Eelco Hoogendoorn < hoogendoorn.eelco@gmail.com> wrote:
Different people work on different code and have different experiences here -- yours may or may be typical yours. Pauli did some quick checks on scikit-learn & nipy & scipy, and found that in their test suites, uses of np.dot and uses of elementwise-multiplication are ~equally common: https://github.com/numpy/numpy/pull/4351#issuecomment-37717330h
Yeah; these are examples of linalg-heavy packages. Even there, dot does not dominate.
My impression from the other thread is that @@ probably won't end up existing, so you're safe here ;-).
I know; my point is that the same objections apply to @, albeit in weaker form.
Einstein notation is coming up on its 100th birthday and is just as blackboard-friendly as matrix product notation. Yet there's still a huge number of domains where the matrix notation dominates. It's cool if you aren't one of the people who find it useful, but I don't think it's going anywhere soon.
Einstein notation is just as blackboard friendly; but also much more computer-future proof. I am not saying matrix multiplication is going anywhere soon; but as far as I can tell that is all inertia; historical circumstance has not accidentially prepared it well for numerical needs, as far as I can tell.
The analysis in the PEP found ~780 calls to np.dot, just in the two projects I happened to look at. @ will get tons of use in the real world. Maybe all those people who will be using it would be happier if they were using einsum instead, I dunno, but it's an argument you'll have to convince them of, not me :-).
780 calls is not tons of use, and these projects are outliers id argue.
I just read for the first time two journal articles in econometrics that use einsum notation.
I have no idea what their formulas are supposed to mean, no sum signs and no matrix algebra.
If they could have been expressed more clearly otherwise, of course this is what they should have done; but could they? b_i = A_ij x_j isnt exactly hard to read, but if it was some form of complicated product, its probably tensor notation was their best bet.