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

[Nick Coghlan]

On 18 March 2014 20:47, Robert Kern <robert.kern at gmail.com> wrote:
> On 2014-03-18 08:02, Nick Coghlan wrote:
>>  > 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.


So, here's the change to PyHeapType object that makes the most sense
to me (assuming both "@" and "@@" are added - drop the new "power"
methods if "@@" is dropped from the PEP):

- add "PyMatrixMethods as_matrix;" as a new field in PyHeapTypeObject
- define PyMatrixMethods as:

    typedef struct {
        binaryfunc mt_multiply;
        binaryfunc mt_power;
        binaryfunc mt_inplace_multiply;
        binaryfunc mt_inplace_power;
   } PyMatrixMethods;

This approach increases the size of all type objects by one pointer.

The other way to do it would be to just add four new slots to PyNumberMethods:

        binaryfunc nb_matrix_multiply;
        binaryfunc nb_matrix_power;
        binaryfunc nb_inplace_matrix_multiply;
        binaryfunc nb_inplace_matrix_power;

This approach increases the size of all type objects that define one
or more of the numeric functions by four pointers, and doesn't really
make sense at a conceptual level. The latter is the main reason I
prefer the separate PyMatrixMethods struct.

Other "should probably be listed in the PEP for completeness" change
is that this will need new opcodes and AST nodes. Reviewing the
current opcode list and node names, I would suggest:

    BINARY_MATRIX_MULTIPLY
    BINARY_MATRIX_POWER
    INPLACE_MATRIX_MULTIPLY
    INPLACE_MATRIX_POWER

    MatMult | MatPow

> Would it be more palatable if the name were something like __altmul__ or
> __auxmul__ rather than __matmul__? Really, it's just a second
> multiplication-like operator. The leading use case for a second
> multiplication-like operator happens to be matrix multiplication, but I
> strongly suspect it will get used for other mathematical things like
> symbolic function composition or operator application (as in "linear
> operator", not +-*/) and maybe some secondary multiplication types in the
> weirder groups and fields (you can bet I will resurrect my Clifford algebra
> module to use this operator for one of the several types of multiplication
> they support). Granted, there is still some awkwardness in that *none* of
> the builtin number types will support it.

I think "matmul" is fine. That makes the primary intended use case
clear, without preventing its use for other purposes (like vector dot
products or more exotic things). The magic method names are "add",
"mul", "div", "mod", etc, even though we occasionally use them for
other purposes (e.g. concatenation, sequence repetition, path joining,
interpolation).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia