3 ms·
Matlab's approach to using * as the matrix multiplier makes sense, because every numerical variable is an array with integers/floats simply being a 1x1 array. U
by NamTaf 13y ago
Matlab's approach to using * as the matrix multiplier makes sense, because every numerical variable is an array with integers/floats simply being a 1x1 array. Using .* then as the elementwise version works.
I'd have personally preferred to see Python do type testing on the variables - it already does. For example:
'quick' + 'fox' = 'quickfox'
3 + 5 = 8
[3] + [5] = [3,5]
So why not make it a case where * on an int or float does the 'standard' multiplication that already exists whereas * on an array does matrix multiplication?
You arrive at the problem of then not having an element-wise version of the multiplication but it's not as if this solves that problem anyway.
What am I missing to make that a problem?
- tomp 13y agoPython's way of treating * as element-wise multiplication when operands are arrays makes it easier to vectorize algorithms - if f(a, b) = a * b, then you can treat a and b as numbers, a number and an array, or as two (multi-dimensional) arrays. In Matlab, you'd have to use *. for that.
- Serow225 13y agoFYI, in MATLAB you'd only need to use .* in the last of your three cases.
- apl 13y ago> You arrive at the problem of then not having an element- > wise version of the multiplication but it's not as if this > solves that problem anyway. Please reread the text. It's exactly what it does, and an exhaustive rationale is given for why both operators are useful and necessary. # Matrix multiplication: a = b @ c # Element-wise multiplication: a = b * c
- NamTaf 13y agoMy apologies, I misremembered that from when I first read it. I'm still on python 2.7 - in 3, does: [3] * [5] = [15] ? Because really it needs to reduce down to that if it's going to make sense from a continuity point of view. edit: To clarify: Is that already part of 3.x, or shall it become part of 3.x once this is implemented?
- apl 13y agoA Python list is not a matrix, so I don't see how this change would entail your statement. Of course, for very specific use cases, a list looks like a numerical vector; the semantics are very different, though.
- maxerickson 13y agoFor numpy arrays, yes (for pretty much all versions). As apl said, Python lists aren't strictly a numerical type. "Numerical type" isn't quite the right description either, but the underlying point is that the design choices for lists don't necessarily favor mathematical convenience or consistency.
- rplnt 13y agoWhat about * *? Would that be confusing? edit: Why not ×? It's unicode source afterall...
- untothebreach 13y agothis is covered in the linked document: Symbols which are not present on US English keyboards start at a significant disadvantage
- rplnt 13y agoAh, thank you. To be honest, I haven't read anything past the paragraph about it being niche.
- jzwinck 13y ago← APL is that way.