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])
826 karma · joined March 26, 2012
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.
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.
> 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.
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.
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?
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
[1]: http://juliaopt.org
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.
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.
- 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.