idunning

Its also very similar to many opinionated Python style guides (minus the !, and where @ is used for decorators [which are a bit meta like macros])

Blog post for the paper: https://deepmind.com/blog/differentiable-neural-computers/

Because index sets in mathematics are typically indexed beginning at 1? The most notable, and relevant, being indexing in matrices

Are you using column generation/Dantzig–Wolfe decomposition?

Not sure what you mean - in case our office gets hit by a meteor?

This is partially fixed in Julia 0.5 (or available now as BaseTestNext.jl in Julia 0.4). Its basically a backwards-compatible rewrite of the former Base.Test that adds the notion of test sets - enabling counting tests by default, but also not immediately failing out on the first bad test and even logging.

StaffJoy (https://www.staffjoy.com/) are using Julia for staff schedule optimization, and a large multinational is using it for train schedule optimization. Its also in use (at least on a trial basis) in the financial sector.

It'd still be a fairly large risk to develop something built-to-last on Julia at this point, so not really the best time for most companies to jump in unless something about Julia really solves a problem they are having.

Indeed, the "Ju" in "Jupyter" is for Julia!

There are definitely some scope issues with the distributed computing functionality, see e.g. https://github.com/JuliaLang/julia/issues/13649 for a general tracking issue (also, that is the 0.3 version of the manual).

Slides: http://iaindunning.com/talks/JuliaCon15JuliaOpt.pdf

Source? One of the best arguments, that is personally relevant to the work I do, is that indexing in math often starts at 1 (e.g. the indexing of rows and columns of a matrix). Translating this to code results in a mental overhead of mapping the math-index to the code-index, a cost I don't pay in Julia.

The problem is that you may have to stray outside that vectorized bubble, and at that point you enter into a two-language situation if you are using R (e.g. RCpp) or Python (Cython?) - which was one of the motivations for the whole Julia language, to avoid needing to do that.

Varies wildly depending on field even within an institution, and is still only for 9 months of the year (pay for the summer either with grants, consulting, or by teaching summer school classes [if there are any]).

Sure, go ahead!

As someone who almost exclusively uses Julia for their day-to-day work (and side projects), I think most of the author's thoughts about Julia are correct. I think the language is great, and using it makes my life better. There are some packages that are actually better than any of their equivalents in other languages, in my opinion.

On the other hand, I've also got a higher tolerance for things not being perfect, I can figure things out for myself (and luckily have the time do so), and I'm willing to code it up if it doesn't already exist (to a point). Naturally, that is not true for most people, and thats fine.

The author isn't willing to take the risk that Julia won't "survive", which is fair. Its definitely not complete yet, but its getting there. I am confident that it will survive (and thrive) though, and continue growing the not-insubstantial community. I have a feeling the author will find their way to Julia-land eventually, in a couple of years or so.

I also interned there, and my team was working 50ish hour weeks on a relatively flexible schedule (e.g. come in 7am-11am, leave 3pm-7pm). Search-related team. I know some teams might be working far more, but that wasn't common as far as I could tell.

I was really impressed that the author included this caveat:

A word on procedure: In this section, we've smoothly moved from single hidden-layer shallow networks to many-layer convolutional networks. It's all seemed so easy! We make a change and, for the most part, we get an improvement. If you start experimenting, I can guarantee things won't always be so smooth. The reason is that I've presented a cleaned-up narrative, omitting many experiments - including many failed experiments. This cleaned-up narrative will hopefully help you get clear on the basic ideas. But it also runs the risk of conveying an incomplete impression. Getting a good, working network can involve a lot of trial and error, and occasional frustration. In practice, you should expect to engage in quite a bit of experimentation.

There is a lot of "magical thinking" amongst people not actively doing research in the area (and maybe a bit within that community too), and I think it at least partly stems from mainly seeing very successful nets, and never seeing the many failed ideas before those network structures and hyperparameters were hit upon - a sampling bias type thing, where you only read about the things that work.

Oh for sure, precomputation is essential. Hell, on a 100-1000 node sparse graph you can store all pairs shortest path info in a really small amount of data (like, PC game feasible for sure). For a game situation I'd be willing to burn a lot of time to crunch down pathing times, but memory pressure is real - so there is a "pareto"/nondominated set of algorithms that explore the tradeoff between memory consumption and run time, and the question is not whether you are 100x faster than another algorithm, but whether you are improving that "efficient frontier" of algorithms by using the same memory as another algorithm but running faster, or running as fast as another but using less memory.

Thats an explicit constraint, not an implicit constraint: The first person has an explicit constraint of "Lets consider only proposals that use existing technology". Thats exactly my point! Except in this case the implicit constraint was "must fit in memory for gaming applications", and I'm saying it should be made explicit. Its not that constraints are bad, just that they need to be shared along with the idea for it to be actionable.

Implicit constraints are the enemy of doing things better, as they allow people to claim basically whatever they want with hidden caveats, which makes it harder for the non-expert to figure out what they need to actually get things done.

Implicit constraints kind of suck for the purposes of creating and sharing knowledge though, don't you think? Even constrained to the domain, there are a wide variety of devices people play games on, so I still think its misleading to say this is 1000x faster than an alternative without the huge caveat that benchmarking is multidimensional.

"Try it and see" will be pretty definitive (assuming you can implement it correctly, which is nontrivial), but it has scaling problems.

I'd argue thats exactly what this talk is about: the presenter claims to have a new method that "wins", i.e. beats something else (A* and some variants on it). So the presenter at least thinks its important, as does the competition he mentions in the talk. He thinks you should try it, because he is saying its better. I'm claiming that without more care, its hard for me to take action on that claim because "better" is not a single dimensional thing, its a rich trade off between at least run time, precomputation time, precomputation memory, and arguably implementation difficulty. It'd be nice to not have to try everything yourself for your particular problem, don't you think?

Agree that everything must be contextualized. My point is, you saw this presentation and liked it because it seems like a good idea, and the performance is apparently good relative to something else. For an engineer (or a theoretician) to reason about that claim of improved performance there needs to be a systematic way to understand it. All I'm saying is that way this was done doesn't allow us to understand it very well - precomputation being a big part of that.

Sure, but thats exactly my point. Given a set of well-stated limitations (like, cannot use more than N^x bytes of storage for an instance of size N, using the same standard library of data structures etc) we can make meaningful comparisons. I could come along with a method that uses O(n log n) memory and crushes this (maybe) - how do we declare a winner now, without some sort of context?

Allowing precomputation seems a little suspect, or at least difficult to incorporate into a comparison. I could offline precompute all pairs shortest path, then I'll be 10^6 faster than Astar, for example. Where do you draw the line? In the Q&A someone asks this, and points out that the precomputation in the video has a lot/all of the shortest paths stored. The speaker says that requires too much memory to store - so basically, arbitrary line here (what is too much?)

Another problem is with heuristics in general: if you are not guaranteed to find an optimal path (which is possible with Astar variants), then you have a two-dimensional way to understand heuristics: run time, and solution quality. e.g. I can give you a bad path very fast.

Finally, implementation data structures and language. Two people implementing the same algorithm in different languages are going to have different performance.

Here is a preprint that addresses these questions for heuristics for two NP-hard problems (MAXCUT and QUBO): http://www.optimization-online.org/DB_FILE/2015/05/4895.pdf

Not sure they are on HN, but I know a few companies at least are using the JuliaOpt[1]/ JuMP[2] stack.

[1] http://juliaopt.org

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

Ouch, "just sad"... would be interested to hear more!

Even if you can't attend, anything you could write up as either a blog post, a Github issue, anything, would be helpful for getting some discussions going around it at the conference I'm sure.

No, I don't think so. I don't think there is much that is going to change with modules in the future, or at least I'm unaware of any open issues about it. What did you have in mind? The hackathon on Wednesday will be a particularly good time to bounce around your ideas, and is free to attend.

Not definite plans, but serious thought is being given to having it in Europe next year if all the necessary bits can come together.

If anyone has any questions about this post or the conference, fire away!

Last year's first conference was a big success in my opinion. Videos are available at http://juliacon.org/2014/, although the speakers weren't mic'ed so the sound isn't so great - we'll be fixing that this year.

I'd say that the actual news is that the Julia founders have found a way to make a living through consulting, enabling them to keep working on an free (in both senses) software. They've also managed to scale to bring on some large contributors too, which is even better. There are three choices, as I see it:

- They would have had to go work for another company that doesn't care about Julia. Its now a free time project.

- They would have had to go work for another company that does care about Julia. They get to work a bit on Julia, but focus shifts to what this company cares about.

- They work for themselves.

Not quite sure why this isn't a more common situation for open-source, it seems like the ideal situation for everyone.

I work on Julia, not for pay, and something like this only encourages me as it is a strong signal of demand by Real People writing Real Code.