Julia and Python: a dynamic duo for scientific computing [video]
lanyrd.com
lanyrd.com
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.
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").
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”).
#include <stdio.h>
int main(void) {
long x = 9007199254740992; // 2^53
double y = 9007199254740992.0; // 2.0^53
long z = 9007199254740993; // 2^53+1
printf("x == y: %d\n", x == y);
printf("y == z: %d\n", y == z);
printf("x == z: %d\n", x == z);
return 0;
}
x == y: 1
y == z: 1
x == z: 0
julia> x, y, z = 9007199254740992, 9007199254740992.0, 9007199254740993;
julia> x == y, y == z, x == z
(true,false,false)
julia> z - y
0.0
So what you’ve essentially done is to make it so that comparisons and arithmetic use distinct promotion rules; comparisons are done without conversions that change value, whereas conversions are applied for arithmetic?
Transitivity failures that arise from clearly specified conversion rules are at least easy to understand once you encounter them. If I understand correctly, to avoid losing transitivity, you’ve introduced a divergence between how types behave in arithmetic and comparisons, and broken the equivalence between x - y == 0 and x == y. To my mind as a numericist and low-level programmer, that’s much worse; it’s the path that Excel started to follow a long time ago, and it leads to all sorts of maddening details when corner cases collide.
My preferred solution for high-level languages is “promote the operands to a type that can represent both exactly” (for the case of double and int64, this would be a floating-point type with at least 64 bits of significand and 11 exponent bits, like the Intel 80-bit format or quad). For a compute-oriented language, there are good performance reasons to avoid that, but it’s definitely the solution that complies with the principle of least surprise.
"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,....
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)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.
[edit: and the preview release will include some cute simple SIMD codes i've written, not the optimal ones, but a really nicely written set none the less.]
However, here at Jane Street at least, many of the traders are picking up and using OCaml. If traders can do, so can scientists. And if it works for OCaml, it'll probably work for Haskell. (Which, honestly, is quite a bit nicer overall.)
Also, the general consensus seems to be that Haskell is easier to learn if you don't already have extensive imperative programming experience. So it's also a good fit for scientists in that sense. If all the needed libraries and tools existed--many do and more will, soon--and it was easy to get up and running, Haskell would be a perfect tool. Happily, it's moving in that direction, becoming simpler and more capable.
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
Hope you guys will still be hiring when I graduate next year. This sounds like a really fun project to work on.