[Python-ideas] Fwd: [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power

[Andrew Barnert]

On Mar 18, 2014, at 1:02, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 18 Mar 2014 09:08, "Nathaniel Smith" <njs at pobox.com> wrote:
> >
> > On Fri, Mar 14, 2014 at 8:15 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > > A few other miscellaneous comments:
> > >
> > > - nice work on the PEP Nathaniel!
> >
> > Thanks!
> >
> > > - as with others, "@" as the operator doesn't thrill me, but I also think it
> > > crosses the threshold of "good enough given the constraints"
> > > - the PEP should probably recommend adding an "operator.matmul" function, a
> > > "PyObject_MatrixMultiply" C API and consider whether or not the new special
> > > method should be given a C level type slot.
> >
> > operator.matmul and PyObject_MatrixMultiply are obvious enough, but
> > I'm afraid I'm not too clear on the tradeoffs about adding a C level
> > type slot, or even entirely sure what the alternative is. (I guess I
> > just assumed that all special methods used C level type slots and
> > there was nothing to think about.) Do you (or anyone) have any
> > thoughts?
> 
> I suspect you're going to want one, as without it, the implementation method ends up in the class dict instead (the context management protocol works that way).
> 
> I suspect the design we will want is a new struct for Py_Matrix slots (akin to those for numbers, etc). The alternative would be to just add more "Number" slots, but that isn't really accurate.
> 
Someone needs to work out how these changes will affect the numpy C API (the Py_Array dotfunc slot, the PyArray interface, etc.). Whoever is doing that--and the numpy C API users who are interested in it--will probably care more about how matmul fits into the python C API than anyone else does.

As for whether this is another numeric operation or a new kind of operation, I think that depends on how you intuitively interpret matrix operations, or rather which intuition numpy and similar libraries should be encouraging. The fact that the proposal suggests that >2d arrays should handle matmul by broadcasting it over the final 2d subarrays seems like it's treating it fundamentally as a numeric operation on (vectors and) matrices. On the other hand, I don't think anyone implementing a split-complex or quaternion library on top of numpy would want to use @ for multiplying their numbers, even if they used @ on the matrices as the implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140318/402ec756/attachment-0001.html>