[Numpy-discussion] It looks like Py 3.5 will include a dedicated infix matrix multiply operator

[Eelco Hoogendoorn]

> 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140316/df49955f/attachment.html>