mlubin

> I remember when using download statistics was enough.

No download statistics are currently available for Julia packages. That's essentially the issue that the Pkg.jl telemetry is trying to address.

Very impressive work, here's the arxiv link: http://arxiv.org/abs/1508.04874

If you're interested in model generation time, have a look at JuMP (https://github.com/JuliaOpt/JuMP.jl). More discussions on the speed of modeling languages at http://arxiv.org/abs/1312.1431 and http://arxiv.org/abs/1508.01982

The only PhD defense I've seen with standing room only. Congrats!

Some light reading for my next long flight.

I really would like to be able to see a proof of how Mathematica calculates a limit, for example. Doesn't need to be human friendly, just verifiable.

This is an impressive job. I'm curious why the arxiv paper uses Julia's benchmark suite but doesn't make any other mention of Julia in the discussion, given that it's quite relevant to this work.

The exchange would be based on the counterparty protocol, which allows anyone with a BTC address to issue and back assets in a decentralized manner. We'll have to see how this decentralization leaks into what it means to be a stock exchange.

To follow up on this, a lot of the overhead from reverse-mode AD can be avoided by flattening out the expression graphs and compiling specialized functions (at runtime). A number of the JuliaDiff packages support this approach. This is not a new idea, but Julia's hooks to LLVM make this surprisingly easy to do.

Should the IPLANG "compiler" try to detect multiple solutions?

A couple of projects have looked at solving the trust issue by implementing a distributed exchange without counterparty risk on top of the bitcoin blockchain: https://www.counterparty.co/ http://www.mastercoin.org/. The idea is that the protocol itself handles escrow and matching orders instead of going through a centralized exchange.

"Hack provides instantaneous type checking via a local server that watches the filesystem."

What does this mean?

Very cool. Missing LGPL v3. I've been looking for a clear explanation of how it differs from LGPL v2.1.

koding.com is another way to get an interactive REPL online: https://koding.com/Julia

For anyone interested in using Julia for numerical optimization/mathematical programming, see http://juliaopt.org/.

We have pure-Julia implementations of standard unconstrained methods [1] as well as a domain-specific modeling language [2] for (integer) linear programming with links to open-source and commercial solvers. Julia's performance and advanced language features such as metaprogramming really make it a great language for optimization [3].

[1] https://github.com/JuliaOpt/Optim.jl

[2] https://github.com/JuliaOpt/JuMP.jl

[3] http://www.mit.edu/~mlubin/juliacomputing.pdf

That's a good tip in general, but it's mostly aimed at addressing type instability. For example, if you have

   x = 1
   f(x)
   x = "foobar"
   f(x)

then each call to f will be optimized for the current type of x. On the other hand, if your code is type stable, as it appears to be here, it will be properly optimized in place by the Julia JIT compiler and there's no need split it into separate functions.

If the goal is to get performance without giving up on Python's existing libraries, why not use Steven Johnson's PyCall (https://github.com/stevengj/PyCall.jl) package for Julia?

I've added a bit of an explanation as to why there's no NumPy version.