Live data from Hacker News

PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

python.org

31–40 of 42 posts

Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

#31

I'm kind of baffled by this. Python has operator overloading, so what's wrong with using * for matrix multiplication? I know there's a bit in the PEP that claims to answer this, but I can't understand their argument. Can someone explain?

It does away with the need for a separate matrix type.

When you are using numpy (most imported non stdlib library according to the pep!) and you have two arrays a and b, a * b is elementwise multiplication.

numpy currently has a matrix type. When a and b are both matrices, a * b is matrix multiplication.

The @ operator would do away with the need for a matrix type. Then, a * b is element wise and a @ b is matrix wise, and a and b are always the same type. This would simplify numpy and lots of things that are based on it.

Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

#32
post #31

I'm kind of baffled by this. Python has operator overloading, so what's wrong with using * for matrix multiplication? I know there's a bit in the PEP that claims to answer this, but I can't understand their argument. Can someone explain?

It does away with the need for a separate matrix type. When you are using numpy (most imported non stdlib library according to the pep!) and you have two arrays a and b, a * b is elementwise multiplication. numpy currently has a matrix type. When a and b are both matrices, a * b is matrix multiplication. The @ operator would do away with the need for a matrix type. Then, a * b is element wise and a @ b is matrix wise…

"The @ operator would do away for a matrix type" which is only an issue because every lib needs to define its own matrix type ? Then why isn't the solution to provide this type in the standard lib ?

Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

#33
post #22

I'm kind of baffled by this. Python has operator overloading, so what's wrong with using * for matrix multiplication? I know there's a bit in the PEP that claims to answer this, but I can't understand their argument. Can someone explain?

It looks like it says there are enough cases where libraries crave two multiplication operators, elementwise multiplication and matrix multiplication, that it makes sense to add an operator to the language.

Would matrix multiplicqtion be useful for anything other than matrices ? I can understand to provide an operator in the language when it's usable by many types, but i don't understand what sense would it have to create an operator just for one type... Even more so when that type isn't part of the language.

Or does it mean that @ would be used just for arrays, and that it would be useful for cases when arrays aren't matrices of numbers ?

Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

#34

I'd really like to see user-defined infix operators such as those in Haskell. There are some baked into the standard library (*+-/ etc), but you can also roll your own, so people could make do until this gets accepted.

You can get cute about it:

http://code.activestate.com/recipes/384122-infix-operators/

The code there overrides | to construct arbitrary operators that are used by wrapping an object in |, like:

    a |x| b
where x defines the custom behavior.

Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

#35
post #32
post #31

Earlier quoted context omitted.

It does away with the need for a separate matrix type. When you are using numpy (most imported non stdlib library according to the pep!) and you have two arrays a and b, a * b is elementwise multiplication. numpy currently has a matrix type. When a and b are both matrices, a * b is matrix multiplication. The @ operator would do away with the need for a matrix type. Then, a * b is element wise and a @ b is matrix wise…

"The @ operator would do away for a matrix type" which is only an issue because every lib needs to define its own matrix type ? Then why isn't the solution to provide this type in the standard lib ?

Because providing a useful (fast) implementation is "highly non-trivial" and doing anything less "would just create a trap for users", says the PEP.

Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

#37
post #27

Earlier quoted context omitted.

I agree. I wish python had the capability to infix functions. Maybe the topic for a new PEP ?

This is this[1] workaround. I wonder if a whole set of infix matrix operations could be added to reduce the need to load numpy for simple tasks. A @* B A @. B A @+ B [1] http://code.activestate.com/recipes/384122/

Yes, but making it part of the language would bring clear error messages in case of misuse, and would allow the use of a different token, e.g. ":", as in smalltalk

Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

#38

Why not overload the already-defined * * ? Matrix multiplication is used much more than matrix exponentation (which can be delegated to methods), and * * is already right associative.

Because already means element-wise power. The reason we need a new operator (@) for matrix multiplication is precisely so we can all the same operators for arrays that we already use for scalars.

Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

#39
post #9

Huh? Isn't it a question of whether you are doing matrix or array ops, so the type system is the issue? I have rarely needed to do elementwide multiply on matrices, and if I do, in Eigenproblem I can just call mat.array() to get an ArrayView. Really, the problem is that NumPy is a crappily designed library primarily intended for array ops, and is just not well suited for linear algebra.

> NumPy is a crappily designed library

I don't think you know what you're talking about.

Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power

#40
post #39
post #9

Huh? Isn't it a question of whether you are doing matrix or array ops, so the type system is the issue? I have rarely needed to do elementwide multiply on matrices, and if I do, in Eigenproblem I can just call mat.array() to get an ArrayView. Really, the problem is that NumPy is a crappily designed library primarily intended for array ops, and is just not well suited for linear algebra.

> NumPy is a crappily designed library I don't think you know what you're talking about.

Try Eigen, you'll agree that NumPy is an array library that had linear algebra support thrown in as an afterthought.
Post reply on HN