3 ms·

> That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpy's solution

> That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpy's solution is as good as introducing two different operators The thing is that the multiplication operation for matrices is matrix multiplication, not elementwise multiplication. When you apply a polynomial like x^2 + y to matrices, you do not want to apply the polynomial elementwise – you want to square the x matrix and add the y matrix to it.

wirrbel 13y ago
If you are doing linear algebra, I agree. Yet linear algebra is not the only thing I want to do with numbers. I think most of the time I do use the elementwise operation, such as: x = linspace(0,10, 1000) y = (x<5)*4.0 z = x**2 + y Of course I can just use matrices and then I have the information at hand that I am doing linear algebra right now: x = matrix([[3, 0], [9, 5]]) Out[28]: matrix([[ 9, 0], [72, 25]]) x**2 + x I think this is not too much boilerplate and gives nice semantic information within the sourcecode. However, if you want to perform this with a 2d array object, you can also use its dot method: In [ 1]: a Out[ 1]: array([[ 9, 0], [72, 25]]) In [ 2]: a.dot(a) Out[ 2]: array([[ 81, 0], [2448, 625]]) In [ 3]: a * a Out[ 3]: array([[ 81, 0], [5184, 625]]) The approach of the matrix object nicely takes into account that operands of a "normal" multiplication `*` commute, so the elementwise multiplication fits the picture here. Wheres matrix multiplication - which is non-associative for most matrices - is performed by a different method.
- east2west 13y ago
  If multiply operator weren't such a big issue, the creators of Numpy wouldn't have attempted to insert a new operator for matrix multiplication into Python. For a dynamic language such as Python operator overloading for such closely related types is a big trouble. If I write a function that uses multiplication, either I use member methods such as "dot" or check for type explicitly, otherwise there is no guarantee what would happen. The worst part is that errors are strictly logic and only way to debug is to trace from end result all the way up to the point of object creation; it isn't pretty.
  - Pxtl 13y ago
    This isn't intrinsic to Matrices vs Number-Arrays. The matrix-mulitplication issue is just a mathy version of the plus-as-sting-concat troubles ("Foo: " + 1 + 1 makes "Foo: 11" while 1 + 1 + " Foo" makes "2 Foo"). There are always holy wars about whether "+" should be string-concat because of that. Both approaches have their merits.
    - wirrbel 13y ago
      I can rarely think of functions foo(arg) where I would like to pass either strings or numbers that uses an operator + which polymorphically concats or performs addition. In this respect like languages that offer special string concatenating operators (like Haskell ++ or Lua with ..). More generally: I think that + and * should always commute for the applied types and mixing them should follow the rules of associativity.
- wirrbel 13y ago
  I meant non-commutative
Stubb 13y ago
I cheered out loud when I first started tinkering with Julia, tested whether multiplication did the right thing with matrices and vectors, and saw that they did. Multiplying two row vectors should give an error! Element-by-element operations should get their own operator, not the other way around. But as a long-time R user, I'm hesitant to bet the farm on Julia for a project at work where it would be ideally suited. Maybe there's a way to squeeze it in on the side.
lloda 13y ago
Sometimes an array of numbers is just an array of numbers. The language shouldn't presume too much about what you mean to do with them. The moment you need an extra dimension (or anything other than 2 really) Matlab's ‘everything is a matrix’ approach falls apart. Matlab is a toy language in so many ways and this is just another one. It's a pity that Julia adopted Matlab's pop matrix semantics instead of some solid and general principles from APL or J. Even modern Fortran would have been a better model for an array DSL. From what I've read of the Julia docs, they actually want you to write loops. But Julia looks great otherwise. With macros and a good compiler, maybe the array features can be fixed at some point.
- shele 13y ago
  Yes, adverbs, ranked matrix operator and some other parts of the APL/J approach I miss a bit and find them tedious to emulate/avoid.
- xerophtye 13y ago
  how exactly does matlab's approach fai? I haven't had that much experience with it, but i do vaguely remember that it supports n-dimensions

wirrbel 13y ago

If you are doing linear algebra, I agree. Yet linear algebra is not the only thing I want to do with numbers. I think most of the time I do use the elementwise operation, such as: x = linspace(0,10, 1000) y = (x<5)*4.0 z = x**2 + y Of course I can just use matrices and then I have the information at hand that I am doing linear algebra right now: x = matrix([[3, 0], [9, 5]]) Out[28]: matrix([[ 9, 0], [72, 25]]) x**2 + x I think this is not too much boilerplate and gives nice semantic information within the sourcecode. However, if you want to perform this with a 2d array object, you can also use its dot method: In [ 1]: a Out[ 1]: array([[ 9, 0], [72, 25]]) In [ 2]: a.dot(a) Out[ 2]: array([[ 81, 0], [2448, 625]]) In [ 3]: a * a Out[ 3]: array([[ 81, 0], [5184, 625]]) The approach of the matrix object nicely takes into account that operands of a "normal" multiplication `*` commute, so the elementwise multiplication fits the picture here. Wheres matrix multiplication - which is non-associative for most matrices - is performed by a different method.

east2west 13y ago
If multiply operator weren't such a big issue, the creators of Numpy wouldn't have attempted to insert a new operator for matrix multiplication into Python. For a dynamic language such as Python operator overloading for such closely related types is a big trouble. If I write a function that uses multiplication, either I use member methods such as "dot" or check for type explicitly, otherwise there is no guarantee what would happen. The worst part is that errors are strictly logic and only way to debug is to trace from end result all the way up to the point of object creation; it isn't pretty.
- Pxtl 13y ago
  This isn't intrinsic to Matrices vs Number-Arrays. The matrix-mulitplication issue is just a mathy version of the plus-as-sting-concat troubles ("Foo: " + 1 + 1 makes "Foo: 11" while 1 + 1 + " Foo" makes "2 Foo"). There are always holy wars about whether "+" should be string-concat because of that. Both approaches have their merits.
  - wirrbel 13y ago
    I can rarely think of functions foo(arg) where I would like to pass either strings or numbers that uses an operator + which polymorphically concats or performs addition. In this respect like languages that offer special string concatenating operators (like Haskell ++ or Lua with ..). More generally: I think that + and * should always commute for the applied types and mixing them should follow the rules of associativity.
wirrbel 13y ago
I meant non-commutative

Stubb 13y ago

I cheered out loud when I first started tinkering with Julia, tested whether multiplication did the right thing with matrices and vectors, and saw that they did. Multiplying two row vectors should give an error! Element-by-element operations should get their own operator, not the other way around. But as a long-time R user, I'm hesitant to bet the farm on Julia for a project at work where it would be ideally suited. Maybe there's a way to squeeze it in on the side.

lloda 13y ago

Sometimes an array of numbers is just an array of numbers. The language shouldn't presume too much about what you mean to do with them. The moment you need an extra dimension (or anything other than 2 really) Matlab's ‘everything is a matrix’ approach falls apart. Matlab is a toy language in so many ways and this is just another one. It's a pity that Julia adopted Matlab's pop matrix semantics instead of some solid and general principles from APL or J. Even modern Fortran would have been a better model for an array DSL. From what I've read of the Julia docs, they actually want you to write loops. But Julia looks great otherwise. With macros and a good compiler, maybe the array features can be fixed at some point.

shele 13y ago
Yes, adverbs, ranked matrix operator and some other parts of the APL/J approach I miss a bit and find them tedious to emulate/avoid.
xerophtye 13y ago
how exactly does matlab's approach fai? I haven't had that much experience with it, but i do vaguely remember that it supports n-dimensions