Neural networks and a dive into Julia | Hacker News Reader

Neural networks and a dive into Julia

blog.yhathq.com

64 pointsglamp19 comments

I am using Julia to casually participate in a bioinformatics contest (I have no bioinformatics background but I am pretty darned good at coding and biochemistry). The technique i'm using involves blasting a subset of the genome with neural nets, and I'll be damned if Julia isn't fast. I haven't benchmarked it against python, but basically the program is running a hybrid swarm optimization/gradient descent technique to find 20:5:1 neural nets; it is able to find test and optimize a swarm of 100 neural nets over 50 iterations in about 2 seconds on my rather slow laptop (2.3 GHz Core i3) A friend of mine is doing the same contest (using python) and his eyes popped out when I told him how efficient Julia was.

which contest?

https://www.synapse.org/#!Synapse:syn1734172

This sounds really cool; I'd love to see a blog post about it :)

I would love to but i got a very late start on this and I'm coming up against a time crunch... I was without my laptop while traveling because I left it in the security line... also for HIPAA reasons I have to be very careful about what gets included in the git push, etc. etc. For various reasons it's a PITA so I might only do a blog post about it if it's successful, and after the contest is over.

Have your friend tried Cython or Numba? It's amazing what couple of extra lines can do with python code ;)

I'm pretty excited about Julia and integrating it into existing infrastructure[0]. The build process though -- even the "release" seems to insist on running git to pulldown code/data from the network -- if Julia devs/release-managers are reading -- what are odds of getting standalone distributions ?

[0] https://news.ycombinator.com/item?id=7173137

We're actually working on static compilation right now, so that you'll be able to compile Julia code to a small binary and distribute it without the runtime. It should be completed over the summer.

Is there any word on Julia for the arm? To use my programs on rpi As it is I have to convert to octave (not hard) but the for loops are slooow.

Isaiah Norton recently got Julia minus some of the external libraries working on ARM [1], but there's still a lot of work to be done. But it is certainly not impossible.

[1] https://github.com/JuliaLang/julia/issues/3134#issuecomment-...

awesome! I know that BLAS is now working on ARM. My RPi debian distro came with mathematica.

Unless I misread, I think you misinterpretted my question: what I'm wanting to do is compile a libjulia.so and link against it, and submit code to it and collect the results.

Grabbing either the git master tip, or even .tgz "distribution" and trying to compile that results in git being fired up and pulling in _something_ new. Can that "something" be included in a distribution so I can effectively just:

  ./configure; make; make install

without git, and without hauling down more code/data over the network ?

There are two different questions here. See my post above for the "link against libjulia" part (possible, not turnkey yet, probably still some warts to work out).

For compilation without internet access: yes, that is possible. There is a special "make source-dist" target which will grab everything you need (see https://github.com/JuliaLang/julia/blob/master/DISTRIBUTING....).

We are not distributing this bundle ourselves right now, but it's worth considering for the next release version.

make source-dist sounds promising. I know we've been cross-posting threads, but I'll just thank you here. :)

The release version is right now relatively minimal [1]: just the repl/compiler, some pure-Julia libraries, and a few important external libraries like OpenBLAS and FFTW. git is bundled to allow installation of additional functionality, and inclusion of git and the integrated "Pkg" system also help facilitate new contributions - which is important at this stage!

There has been discussion of the idea of a larger "platform" distribution including snapshots of various important packages, so that more extensive functionality is available in a single installer. No timeframe promises, but it is on the radar, and this will be very important for the next phase of adoption.

Regarding the "call Julia from C" question in the post you linked, this is technically possible, but not turnkey: https://groups.google.com/d/msg/julia-dev/qdnggTuIp9s/BoQSNG...

[1] As compared to default-install of some other technical environments. There is also a contingent pushing for a much more minimalist distribution for language-only/non-mathy applications!

re: call Julia from C -- understood -- that part I'm happy to hack w/ and see what happens. Regarding git for a build phase -- (because it's difficult to read emotional intent on the internet, let me say: I appreciate this work on Julia, and how difficult project management is. Much respect. But...) I think I disagree with you about what a "distribution" is - it should be a snapshot, and whether there are two versions (base, "batteries installed"), or additional packages to optionally install later is inconsequential - a "distribution" should be self-contained and fully baked. The devs/hackers can pull from tip of master and get the "live" build scripts, but that shouldn't be included a release -- release != repository.

Again, much respect. Consider my comment food for thought.

(We're both mixing threads - see below!). No worries at all :) I understand what you mean now, and I've spent enough time in places with slow/no internet connectivity, so I'm very partial to the idea. I'll file an issue about it and see what other folks think.

Interesting. OP (if you're around): I noticed in the confusion matrix that everything was classified to the middle classes (5, 6, 7). That makes sense because the 3s, 4s, and 8s are rare and "true 8s" are still most likely to have a high probability on the 7 class, because there are far more 7s in the data. Did you analyze approximate correctness for the probabilities, or consider sampling from the computed probabilities rather than classifying to the highest one, to see where that led?

Hi there.

That ml problem is more for example than for rigor. In fact that particular problem would probably be better suited for other algorithms (eg, random forest).

My background's in biomedical imaging, so I'm quite fond of problems with skewed class distributions. Though I didn't have time to explore this particular one further.

The code's all openly available if you want to give it a go though :)

Reply on news.ycombinator.com