On 15 March 2014 00:04, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 15 Mar 2014 09:56, "Greg Ewing" <greg.ewing@canterbury.ac.nz> wrote:
Antoine Pitrou wrote:
It depends how the vectors are layed out (horizontal @ vertical or vertical @ horizontal).
The definition of @ in the proposal is such that two 1D arrays is interpreted as horizontal @ vertical.
Oh, nice! Maybe the PEP should include implementing that for lists and our other 1D sequence types?
I don't think that that should be included in the PEP. It's unlikely that many users will want that and if they do it will be subject to bike-shedding of issues that aren't directly relevant to the problem that this PEP tries to solve. It'll get brought up on python-ideas some time in the next couple of years and then interested parties can bike-shed over it separately (with the benefit of an existing implementation of the operators in numpy for comparison).
Also, I just remembered another minor error in the PEP - as of Python 3.3, memoryview.cast() allows the creation of multidimensional views, so the PEP is incorrect in saying that can't be done with the builtins/stdlib.
I'm getting a bit of déjà vu here: https://mail.python.org/pipermail/python-dev/2013-September/128463.html Has this changed since then? I'd like to know how to use memoryview to create a 2D matrix of integers or floats. Also even if it is possible to create a 2D view in the stdlib I don't think that the stdlib should try so support matrix multiplication unless it is prepared to try and do so efficiently. Numpy delegates this task to the underlying BLAS library which will usually be not just asymptotically more efficient than a naïve algorithm but also heavily micro-optimised. I doubt that the Python core wants to grow a dependency on having a BLAS library so unless someone wants to reimplement this part of one it's best to leave it out. A big +1 on the PEP from me. I think this brings numpy on a par with Matlab for linear algebra. Matlab also has other matrix related operators such as matrix left and right divide with \ and / but I think that these are triviallising what should be understood as non-trivial operations and are also overloaded to mean too many different things (given different array shapes). Similarly Matlab has made a big mistake in having the default multiplication operator be matrix multiplication which creates a significant pitfall for new users and becomes a common source of problems that people have to work through every time they start debugging their code (it's just a time waster really). Some people have complained that the @ symbol looks clunky. Personally I think it's important that this operator should be very distinctive. Using an innocent-looking operator for matrix multiplication has been tried before and based on ~7 years of teaching Matlab I would say that it's a bad idea. Oscar