6 ms·

Writing fast code in Julia requires less effort than it does in Python or R. You don't have to drop down to Cython or Rcpp to get good performance. If you write

Writing fast code in Julia requires less effort than it does in Python or R. You don't have to drop down to Cython or Rcpp to get good performance. If you write an algorithm in Julia the same way you'd write it in C, it will achieve equal performance. If you write it the same way you'd write it in Python or R, it may not be optimal due to the cost of memory allocation, but it's still faster than Python or R. Julia is more concise than Python. The language was designed to work with multidimensional arrays; it wasn't bolted on afterwards. There is no difference between a 2D array and a matrix; * always does matrix multiplication and .* always does element-wise multiplication. There is no awkwardness involving differences between NumPy arrays and Python lists. Everything has a type, and you can make a multidimensional array that efficiently stores values of any type. You can define your own types and define how arithmetic operators act on them with a minimal amount of code. Julia's type system makes writing efficient algorithms easy without sacrificing any performance. If you define your own immutable type and define your own operators on it, Julia can make those operators run as fast as they would on ordinary values. In addition to general matrices, we have diagonal, symmetric, and tridiagonal matrices. The same routines that work on general matrices work on these as well with the same syntax, just more efficiently. Julia uses multiple dispatch instead of traditional class-based OO. Methods are not a part of the object; instead, they operate on the object. Different methods with the same name can be defined to work on different types, or a single method can operate on a set of types, but the functions it calls may be implemented differently for each of these types. This is a better fit for technical applications, where the data doesn't change much but the methods do. Julia is homoiconic, which is more useful than this article makes it seem :). It's easy to write code that writes code. If built-in language features aren't enough to get good performance with concise syntax, you can write a hygenic macro that does this for you.

wirrbel 13y ago
To the rescue of numpy: A matrix from linear algebra and a 2D array are not exactly the same. In Python they are different convertible types and I think in practice it is hardly a drawback. That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpys solution is as good as introducing two different operators (with one being an awkward .*) I love the multiple dispatch part about julia though. My fear however is, that unlike Python, Julia will lack enough libraries, especially on the unscientific part (GUI, databases, network, all the other stuff you need).
- StefanKarpinski 13y ago
  > 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.
kldavenport 13y ago
Check out the Python JIT compiler NUMBA. It compiles annotated Python and NumPy code to LLVM (through decorators). It's been wicked fast for my use cases: http://numba.pydata.org/ http://numba.pydata.org/

wirrbel 13y ago

To the rescue of numpy: A matrix from linear algebra and a 2D array are not exactly the same. In Python they are different convertible types and I think in practice it is hardly a drawback. That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpys solution is as good as introducing two different operators (with one being an awkward .*) I love the multiple dispatch part about julia though. My fear however is, that unlike Python, Julia will lack enough libraries, especially on the unscientific part (GUI, databases, network, all the other stuff you need).

StefanKarpinski 13y ago
> 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.

kldavenport 13y ago

Check out the Python JIT compiler NUMBA. It compiles annotated Python and NumPy code to LLVM (through decorators). It's been wicked fast for my use cases: http://numba.pydata.org/ http://numba.pydata.org/