5 ms·

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 claim

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?

gradys 13y ago
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.
- bsaul 13y ago
  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 ?
aaren 13y ago
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.
- bsaul 13y ago
  "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 ?
  - ptx 13y ago
    Because providing a useful (fast) implementation is "highly non-trivial" and doing anything less "would just create a trap for users", says the PEP.
  - aaren 13y ago
    It doesn't have to be used for matrix multiplication. Other libraries might overload it as something else.

gradys 13y ago

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.

bsaul 13y ago
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 ?

aaren 13y ago

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.

bsaul 13y ago
"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 ?
- ptx 13y ago
  Because providing a useful (fast) implementation is "highly non-trivial" and doing anything less "would just create a trap for users", says the PEP.
- aaren 13y ago
  It doesn't have to be used for matrix multiplication. Other libraries might overload it as something else.