[Numpy-discussion] [RFC] should we argue for a matrix power operator, @@?

[Christophe Bal]

Hello.

Maybe a solution would be to not see @ and @@ only from the matrix point of
view.

Why ? The philosophy of Python is to give total control of the infix
operators +, * and ** for example via the magic methods. So it can be also
the case for @ and @@ that could be use for something else
that <matrix>@@<int>.

So what we can expect from A@@B@@C. I will say that is the same as a**b**c
because a human goes from top to down (but this is not a general convention
in CAS).

Ok guy but what can we do for <matrix>@@<matrix>@@<matrix>. Just raises an
error. The programmer has the possibility to use @@ as ** but it has to
take care of the meaning regarding to the types of the objects. This is for
example what we expect for <matrix>@@pi even if we mathematically can give
a meaning to that for some matrices.

Do not forget also that a direct computation of the inverse of a matrice is
a complicated things, and that integer power of matrices have to be
cleverly build, but I'm sure that everyones here know that.

*So standard Python can...*

   - only proposes multiplication of matrices,
   - and for the power of matrices, just indicates that there is a magic
   method associated to @@ and explains that regarding to the complexity of
   this problem, it will be the job of the programmer to implement it.


I think the problem from Guido's point of view is the asymmetrical type
domain for operations. All the numeric operators are from <number>*<number>
to <number>.

Hoping that my frenchy english is clear enough.
Chrisopthe BAL


PS: maybe a good question for Python would be to see if other operators
could be useful. For CAS, I would like to have the possibility to use f°g
for composition, even if it is more for pedagogical reason, and f°°n for
dynamical systems. But this is just a dream...


2014-03-15 6:39 GMT+01:00 Jaime Fernández del Río <jaime.frio at gmail.com>:

> On Fri, Mar 14, 2014 at 9:32 PM, Nathaniel Smith <njs at pobox.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
>> connectivity.
>> - '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.
>
> Jaime
>
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140315/c5204b3d/attachment.html>