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.f...@gmail.com>: > On Fri, Mar 14, 2014 at 9:32 PM, Nathaniel Smith <n...@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@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion