[Numpy-discussion] vectorization vs. numpy.linalg (shape (3, 3, 777) vs shape (777, 3, 3))
njs at pobox.com
Sun Mar 5 14:20:19 EST 2017
On Sun, Mar 5, 2017 at 7:46 AM, Nico Schlömer <nico.schloemer at gmail.com> wrote:
>> I am honestly not sure where you are going at. This order seems the more
>> natural order for most operations.
> Not sure what you mean by "natural". The most basic operations like `a +
> a` are several times faster than `a[...,0] + a[..., 1]`. Perhaps one can
> come up with code examples that don't use those operations at all, but I
> would guess that'll be a rare case. My point: If your code uses vector
> operations (as `+`) _and_ numpy.linalg functions, your vector operations
> will be several times slower than necessary.
I guess it seems odd that you're thinking of "vector operations" as
always meaning "operations on two slices of the same array"? I feel
like that's a vanishingly small percentage of vector operations.
Surely a + b is a lot more common than any of those?
In any case, the reason linalg works that way is to be consistent with
the general numpy broadcasting rule where you match indices from the
right, which is certainly not possible to change. The reason
broadcasting works that way is that in the common case of C memory
layout, it makes vectorized operations like a + b faster :-).
In theory it should also make the linalg functions faster, because it
means that each call to the underlying 'det' routine is working on a
contiguous block. If they worked from the left then we'd almost always
have to copy the whole matrix into a temporary before we could
actually do any linear algebra. (Though since linear algebra routines
usually have super-linear complexity this might not matter much in
Nathaniel J. Smith -- https://vorpus.org
More information about the NumPy-Discussion