Julia and Python: a dynamic duo for scientific computing [video]

http://lanyrd.com/2013/scipy/schhyz/

by luu • 13 years ago

136 18 13 years ago

astrieanna• 13 years ago

I'm very impressed by the smoothness of the Julia-Python interoperation they demonstrate here. The IPython implementation (IJulia) has made a lot of progress since then and is really cool.

coolsunglasses• 13 years ago

Clojure and Incanter have served me well in the place of Python and R lately.

jparmer• 13 years ago

We're thinking about adding a Julia API: https://plot.ly/api

Hit us up if you'd like to be a part of this or have input. And hey, we're also hiring: https://plot.ly/jobs

daemonk• 13 years ago

Nice. I know plenty of biologists who would love to have a simple to use interface for making publication ready figures. Excel just isn't cutting it anymore with the complexity of the data we get today.

Hope you guys will still be hiring when I graduate next year. This sounds like a really fun project to work on.

cabacon2• 13 years ago

To be fair, I haven't used Julia, but I have heard it suggested as an open-source replacement for Matlab/Octave. To that end, I hope it turns out well. When I was looking to see where the project was at, I got nervous when I read a recent thread on the -dev mailing list: https://groups.google.com/d/msg/julia-dev/2JcZdFKisis/Ag9rBJ...

In particular, the line "[...] I suspect that isequal should be transitive (it has to be for hashing to work), while == will not be transitive. We still need some coherent theory of what == means." made me wince. If one of the benefits that the video makes for Julia over Python is a type system, then there ought to be a pretty well-developed sense of how promotion and equality between types is going to work. That seems like a piece of the language whose theoretical underpinnings should have been nailed down already.

tomrod• 13 years ago

Have you considered pointing this out to them? Perhaps the people in the project are unaware that this is a solved problem.

cabacon2• 13 years ago

Not really - the discussion on the thread makes it sound like the kind of thing that comes up from time to time anyway. If I had to guess, I'd expect that it happened based on the mission of making something that was good enough to replace matlab, and going from the matlab interface people were used to and working backwards, rather than starting from a concept of what a language ought to be like and working forwards. Given my understanding of their aim and the kinds of things I have read about Matlab at http://abandonmatlab.wordpress.com/, I suspect that "close enough to matlab to have people jump ship" and "first-principles CompSci" language aren't really going to intersect very hard. Given the low popularity of some of the first-principles programming languages, that may be okay?

That said, I'm encouraged to see so many people interested in it and contributing to it. My perspective, though, is that of a C/Fortran HPC person who is cheering for things that will help people move to a more scalable coding environment. I was looking at Julia to see if it was an alternative to Octave for university users; the impression I got was that it was still too subject to change to recommend at this point.

doug1001• 13 years ago

i don't think Julia is viewed by the relevant communities as a replacement for Matlab, Octave, et al; likewise, i don't think that was the purpose underlying the Julia project.

"Scientific Python"--ie, python + NumPy + SciPy + Matplotlib (and perhaps including iPython) have been a de facto open source replacement for Matlab for some time now. This is apparent if you look at the similarity in syntax--eg, most significantly) NumPy copied Matlab's beautifully dense array-indexing syntax. Performance-wise, across a reasonably complete set of benchmarks reflecting the workflow of a typical user, Scientific Python and Matlab are interchangeable (https://modelingguru.nasa.gov/docs/DOC-1762).

Instead, what the Julia creators wanted to do, as i understand it, is provide an array-oriented language having true compiled -code performance; this level of performance, Scientific Python user can only achieve through additional steps in their workflow that usually involve re-writing performance-critical portions of the code in another language and compiling them in-line, e.g., cython, weave (C++ inline), numexpr (JIT for a limited set of NumPy functions), direct access to the BLAS (provided via a SciPy module), swig, f2py,....

iskander• 13 years ago

cython, weave (C++ inline), numexpr (JIT for a limited set of NumPy functions), direct access to the BLAS (provided via a SciPy module), swig, f2py,....

I agree with your comment, I just want to add a few more Python performance options to the mix:

   * Numba (http://numba.pydata.org/)

   * Parakeet (https://github.com/iskandr/parakeet)

   * Pythran (https://github.com/serge-sans-paille/pythran)

bachback• 13 years ago

The problem is not ==, but == for rationals.

StefanKarpinski2• 13 years ago

Most languages don't have a coherent theory of what "==" means. Consider all the well-known problems in JavaScript and PHP, where "==" isn't even symmetric and certainly isn't transitive. Equality isn't transitive in C or Java either and in Python and Ruby it's a bit of a free-for-all. Most languages can sweep their lack of a theory for "==" under the carpet simply by saying "here are the rules, learn 'em" since you can't create your own numeric types or add behaviors to "==". In Julia, since anyone can add new numeric types that "==" will apply to, we need something better: we need to be able to tell people exactly what "==" means so that they can correctly implement it for their own types. This choice has deep implications for arithmetic (does "x == y" if and only if "x-y == 0"?), hashing and promotion, among other things.

The particular thread you're quoting was about a change (by me) that briefly altered the promotion behavior of rational numbers (and was reverted before any harm was done). It was fairly rapidly concluded that the existing behaviors of ints and floats were correct and that rationals should fall in line with those. Specifically, the correct behavior of "==" is that it must be transitive ("x == y" && "y == z" ==> "x == z"), but "x-y == 0" may occur in cases where "x != y" (e.g. when "x = 2^53+1; y = 2.0^53").

stephencanon2• 13 years ago

Can you give an example of “==" failing to be transitive in C? The standard defines “==“ as a predicate that tests the numerical equality of the values of the (promoted) operands; unless you can hide something very clever in the promotion rules, that’s going to make the relation transitive. [Edit: as Stefan points out, there are cases where C’s promotion rules cause values to be rounded (which should have been obvious) — int32 to float32 and int64 to float64 in particular; this naturally leads to transitivity failures].

I’m also curious about your distinction between x == y and x - y == 0. Those are equivalent expressions for all reasonable integral and floating-point types (they fail to be equivalent when floating-point types lack denormals, but that’s “not reasonable”).

Mikeb85• 13 years ago

It's interesting. When Julia first came onto the scene, it seemed everyone was gung-ho to rewrite everything in Julia. Now they've capitulated and are simply incorporating Python bits...

Julia and Python: a dynamic duo for scientific computing [video]

Related Stories