idunning

Not completely. Not an expert on this, but I believe issue at least partially stems from the interaction with the older LLVM JIT we are using. We are moving to the newer LLVM JIT in the 0.4 release cycle and I understand this will address the issue.

There is this, which is similar but not quite the same:

    julia> "hello" |> reverse |> uppercase
    "OLLEH"

I used Julia's in-built profiler to look at your code. Almost all the work is done, as you'd hope, on lines 20, 22, 33, and 35. I added @inbounds to lines 20 and 35, figuring that line 22 is mostly just the effort of calculating tanh. This dropped the running time on my computer from 10.7 seconds to 6.4 seconds, so about 60% of original running time. If I compile with gcc (gcc rnn_perf.c -O2 -o rnn_perf -lm) and run that, I get 6.2 (O3 is worse). That might not be how you compiled the C version, but regardless it looks like your C time was about 46% of the original Julia time, so its getting close. Three-fifths of the work now is in the tanh line. I'll submit a PR.

Great stuff. I think the author may be using the release version 0.2, as the boot time issue has been rectified now for the most part in the next release, 0.3. The next big slow-load issues is packages, that'll be post 0.3 though.

They are indeed, Julia has replaced the combination of Python (prototyping) and C++ (implementation) for me for scientific work - would be painful to go back.

Can anyone describe the improvements to Beamer support?

That visualwebsiteoptimzer page is mathematically confused and the simulation is fatally flawed, I wish it'd disappear from the internet. Check the comments.

Exactly - the C interop is used almost exclusively for connecting to existing libraries.

Very cool. We had a similar experience when implementing the Simplex method for linear optimization, except we evaluated PyPy versus Julia instead of Cython. Its similar in that it benchmarks "just" the language, not BLAS, which is common pitfall I see when people compare the two. I guess at this point, a year or so later, it isn't surprising to me anymore that Julia is as fast as it is for these sorts of computational tasks - its been demonstrated pretty comprehensively at this point.

Slides: http://www.mit.edu/~mlubin/informs2013.pdf

Paper: http://arxiv.org/abs/1312.1431

Is there/what is the best FOSS alternative to this? Something built on D3, perhaps?

I don't believe that is correct, re: UCB1

There are probably a few ways to prove the result now, but one (nicely general) way to prove that online learning result would be the method of multiplicative weights: https://www.cs.princeton.edu/~arora/pubs/MWsurvey.pdf

This is a big issue for some people in my lab too. There are interesting efforts towards this, check out Julietta:

https://github.com/tknopp/Julietta.jl

It is open-source software, not a walled garden - there are going to be multiple options, and they are not going to all be named ["PLOTTINGISHERE$i" for i in 1:4].

If you like MATLAB/pyplot/matplotlib style, PyPlot.jl is for you.

If you like ggplot2, Gadfly.jl is for you.

If you like gnuplot, Gaston.jl is for you.

Finally, but not least, is Winston.jl, which is its own thing altogether.

I think in many cases its good for packages that overlap to come together/one to become dominant, but I don't think that applies here.

https://github.com/stevengj/PyPlot.jl

https://github.com/dcjones/Gadfly.jl

https://github.com/mbaz/Gaston.jl

https://github.com/nolta/Winston.jl

A lot of mathematics (and real life, but lets not go there) is written 1-based, which makes it quite a pleasure to translate algorithms into Julia. But I don't think its a big criticism OR selling point really - sometimes its good, sometimes its bad. I personally enjoy it, and I make less indexing errors than I do when writing array/matrix intensive code in C++.

Startup times are not fantastic with packages. This hasn't been a big area of focus yet, but there is a roadmap for getting this down.

Its definitely a typo. Stable release is currently 0.2 (released near end of 2013) and upcoming version is 0.3 (a month or so away).

I'd agree about it being a fluff piece, although I think the binary options you present aren't fair.

I'm not a core developer on Julia, just a user and package creator. It is geared towards technical/scientific computing, and excels in that task - it has replaced the combination of Python and C++ I used previously. I think what Jeff Bezanson is saying is that there is nothing intrinsically unsuited about Julia for doing web programming or desktop applications. It benefits from a fresh start in this respect, and also by using best-of-breed libraries from OpenBLAS to libuv. This is in contrast to other languages for technical computing like MATLAB or R which I wouldn't consider to be practical choices for making, for example, a math-as-a-service application (although R is getting into this territory with things like shiny).

Just a little hacked together holiday project, interested to hear how you find it useful/useless!

They can be OK if being optimal isn't a concern, or the problem isn't too hard.

Not sure exactly, but I guess the dirty tricks are what really makes the difference. If you want to optimally solve a TSP, and know you are optimal when you stop, this is the approach you would use in practice - as far as I know it is the only thing that scales well. Its the underlying principle behind Concorde (http://www.math.uwaterloo.ca/tsp/concorde.html) which AFAIK is the best TSP solver out there.

We implemented a "serious" version of simplex algorithm for linear programming (sparse-matrix / sparse-vector operations that can't be handled by standard libs), and we got performance no worse than half of the equivalent code in C++ with bounds checking, slides here: http://www.mit.edu/~mlubin/informs2013.pdf

Must be frustrating! Octave provides a valuable service to the community.

Julia does support vectorization just like MATLAB, but I think what you may be referring to are some of the speed traps that currently exists where undesireable/unnecessary copies occur. This is often in practice the reason that writing devectorized code is better in Julia right now.

But, this issue is well-identified in the Julia dev community, and is on the roadmap for 0.3: https://github.com/JuliaLang/julia/issues/4853

Agreed - its always a sinking feeling to see code attached to a paper and see that its MATLAB or, even worse, MATLAB+some toolkit/addon. Of course, still better than seeing a paper without ANY code...

I think its fair to say that it shines for numerical computation, but you can perform other tasks with Julia with ease.

For example, the idea of writing some number-crunching as a webservice with MATLAB or Octave is not an option, but with Julia is totally possible (and has been done more than once already) - and it builds on strong foundations (e.g. libuv). Heres an example (disclaimer: my own site) http://iaindunning.com/2013/sudoku-as-a-service.html

I don't think speed is the only reason for using it - from my perspective in this context its more like free (in both senses) drop-in replacement for MATLAB, but with less "weirdness" than MATLAB (and Octave) that is also fast.

I also think any "immaturity" is only really in the package ecosystem, especially after the release of 0.2. Even then, the package ecosystem is strong for the things that people really need (naturally), and of course you can call any Python package from Julia if you want as well.

Here are the slides for a recent talk we gave about JuliaOpt:

https://docs.google.com/presentation/d/1FlHt245YxPXFwOHmxLYW...

That line of development hasn't been pushed very hard yet, but the fundamentals are good. For a example, check out http://iaindunning.com/2013/sudoku-as-a-service.html where I make a nice little webservice.

I'm taking this class right now and it is certainly an interesting twist on the topic - its fun to see how many different ML techniques solve variants of a single base problem that you can analyze with statistical learning theory. Also: how many different regularizations are equivalent, and how some "intuitive", ad-hoc-seem-to-work regularizations you might think up in isolation actually can be theoretically justified. It contrasts with the more traditional, also grad-level 6.867 ML class.

It is primarily to showcase JuMP, yes. I also hoped it'd introduce more people to MIP, something not often covered in CS education.

As for using other techniques, I don't think it necessarily makes more sense to use them. The natural statement of the problem is an optimization problem, not a constraint satisfaction problem, so using an optimization method seems reasonable to me. On problems that are highly constrained (few/one feasible solution[s]) it would probably make more sense to try a constraint programming approach, but this particular problem has many (too many?) feasible solutions so I don't think there is any reason to believe they'd be better.

One downside to MIP is the need to model the logical constraints as linear equations, which is perhaps less expressive than the way you can often express constraints in constraint programming languages.

Theres been some work towards that: https://github.com/hackerschool/Meddle.jl is "middleware", and https://github.com/hackerschool/Morsel.jl is a framework. The main issue right now is that no one is particularly pushing/has a strong need for that kind of thing right now. I speculate that math-heavy services like the one described in this post will probably sit side-by-side with other services written in more traditional languages in the short to mid-term.