[Numpy-discussion] [RFC] should we argue for a matrix power operator, @@?
Jaime Fernández del Río
Sat Mar 15 00:39:23 CDT 2014
On Fri, Mar 14, 2014 at 9:32 PM, Nathaniel Smith <email@example.com> wrote:
> Here are the interesting use cases for @@ that I can think of:
> - 'vector @@ 2' gives the squared Euclidean length (because it's the
> same as vector @ vector). Kind of handy.
> - 'matrix @@ n' of course gives the matrix power, which is of marginal
> use but does come in handy sometimes, e.g., when looking at graph
> - 'matrix @@ -1' provides a very transparent notation for translating
> textbook formulas (with all their inverses) into code. It's a bit
> unhelpful in practice, because (a) usually you should use solve(), and
> (b) 'matrix @@ -1' is actually more characters than 'inv(matrix)'. But
> sometimes transparent notation may be important. (And in some cases,
> like using numba or theano or whatever, 'matrix @@ -1 @ foo' could be
> compiled into a call to solve() anyway.)
> (Did I miss any?)
I'm not really arguing for it, and I am not sure how, or even if, it fits
in the general scheme. But for completeness sake, 'e @@ Matrix' is used in
some treatments of linear systems of differential equations, where:
d<vector>/dt = <matrix> @ <vector>
would have solution
<vector> = e @@ (<matrix> * t) @ <vector_0>
I don't think it makes any sense to use it as such in the context of numpy,
as I think it would make broadcasting undecidable. But there may be
parallel universes where having n @@ <matrix> and <matrix> @@ n both with
well defined, yet different meanings may make sense. It is my impression
that in this entirely made up scenario you would want e @@ A @@ 3 to be
evaluated as (e @@ A) @@ 3. Which probably has more to do with the fact
that the two @@ mean different things, than with the associativity that
repeated calls to the same @@ should have.
Personally I couldn't care less, and if I had a vote I would let @@ rest
for now, until we see how @ plays out.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion