6 ms·

An Introduction to Machine Learning in Julia

shoyer 10y ago
This is a cute example, but it misses the mark. The efficient way to do fast nearest neighbor search is with a search tree (e.g., KDTree or BallTree), which brings down query time from linear to logarithmic in the number of items.
- staticfloat 10y ago
  Agreed, but since those two concerns are separate (algorithmic improvement vs. taking advantage of parallel hardware) I'm not sure I'd categorize this as "missing the mark" so much as that's a further improvement that could be made. For a blog post that looks to be an attempt to tout methods to easily exploit data parallelism, I think focusing on algorithmic improvement would be counter productive.
  - adrianN 10y ago
    I tend to agree, but there is a tendency to throw hardware at things where some algorithmic improvements would work much better. See for example this blog post http://www.frankmcsherry.org/graph/scalability/cost/2015/01/15/COST.html http://www.frankmcsherry.org/graph/scalability/cost/2015/01/...
ovis 10y ago
I was a bit disappointed that there wasn't much detail given about the problem being attacked, and no information about the results other than some timings. Sure, Julia's nice, but what are we looking at here? Also, there's talk about how slick this is when using IJulia notebooks. It would be cool to provide a link to an actual notebook.
MrQuincle 10y ago
It would be great to see the difference with other languages. So why Julia and not R, or Matlab, or Python? Is it more elegant, more concise, does it have more libraries, can it be run in parallel better? That would be great to know!
- Lxr 10y ago
  Julia is a lot (lot) faster than Python, Matlab or R. This doesn't matter so much if you're gluing library calls together (if using well-known ML algorithms that use native BLAS/LAPACK etc) but for custom stuff Python et al are just too slow. Julia is comparable to C++ in speed (not as fast, but within an order of magnitude in my experience) and it's MUCH more fun to write. There are definitely not more libraries though, it's still a young project.
  - dnautics 10y ago
    sort of: Julia is JITted, so there can be some overhead, and if you're not careful about how you program, the overhead can be high (and it's not hard to be careful), but the cost of this overhead diminishes as you run over increasing amounts of data. Also some things like Julia's text IO are super slow because of the architecture of how functions like print() work (I think this is a work in progress) so logging may incur a cost. Don't get me wrong, I love Julia and actually get paid to code in Julia, and it's a real joy of a programming language to work in (I'd put it close to ruby in terms of programmer satisfaction)... Just think that overblowing speed claims is counterproductive.
    - tomrod 10y ago
      > Don't get me wrong, I love Julia and actually get paid to code in Julia, and it's a real joy of a programming language to work in (I'd put it close to ruby in terms of programmer satisfaction)... Just think that overblowing speed claims is counterproductive. Whoa! Who is using Julia in production? I'm a data scientist in a large corp that has successfully converted folks to Python, and would love to use Julia for my custom stuff!
      - dnautics 10y ago
        I wouldn't call it 'production'. I'm prototyping experimental number systems for high-performance computing and my supervisor has been doing it in mathematica to date, which is so glacial it's unacceptable. Took hours to do a calculation that julia can do in seconds.

This is a cute example, but it misses the mark. The efficient way to do fast nearest neighbor search is with a search tree (e.g., KDTree or BallTree), which brings down query time from linear to logarithmic in the number of items.

staticfloat 10y ago
Agreed, but since those two concerns are separate (algorithmic improvement vs. taking advantage of parallel hardware) I'm not sure I'd categorize this as "missing the mark" so much as that's a further improvement that could be made. For a blog post that looks to be an attempt to tout methods to easily exploit data parallelism, I think focusing on algorithmic improvement would be counter productive.
- adrianN 10y ago
  I tend to agree, but there is a tendency to throw hardware at things where some algorithmic improvements would work much better. See for example this blog post http://www.frankmcsherry.org/graph/scalability/cost/2015/01/15/COST.html http://www.frankmcsherry.org/graph/scalability/cost/2015/01/...

ovis 10y ago

I was a bit disappointed that there wasn't much detail given about the problem being attacked, and no information about the results other than some timings. Sure, Julia's nice, but what are we looking at here? Also, there's talk about how slick this is when using IJulia notebooks. It would be cool to provide a link to an actual notebook.

MrQuincle 10y ago

It would be great to see the difference with other languages. So why Julia and not R, or Matlab, or Python? Is it more elegant, more concise, does it have more libraries, can it be run in parallel better? That would be great to know!

Lxr 10y ago
Julia is a lot (lot) faster than Python, Matlab or R. This doesn't matter so much if you're gluing library calls together (if using well-known ML algorithms that use native BLAS/LAPACK etc) but for custom stuff Python et al are just too slow. Julia is comparable to C++ in speed (not as fast, but within an order of magnitude in my experience) and it's MUCH more fun to write. There are definitely not more libraries though, it's still a young project.
- dnautics 10y ago
  sort of: Julia is JITted, so there can be some overhead, and if you're not careful about how you program, the overhead can be high (and it's not hard to be careful), but the cost of this overhead diminishes as you run over increasing amounts of data. Also some things like Julia's text IO are super slow because of the architecture of how functions like print() work (I think this is a work in progress) so logging may incur a cost. Don't get me wrong, I love Julia and actually get paid to code in Julia, and it's a real joy of a programming language to work in (I'd put it close to ruby in terms of programmer satisfaction)... Just think that overblowing speed claims is counterproductive.
  - tomrod 10y ago
    > Don't get me wrong, I love Julia and actually get paid to code in Julia, and it's a real joy of a programming language to work in (I'd put it close to ruby in terms of programmer satisfaction)... Just think that overblowing speed claims is counterproductive. Whoa! Who is using Julia in production? I'm a data scientist in a large corp that has successfully converted folks to Python, and would love to use Julia for my custom stuff!
    - dnautics 10y ago
      I wouldn't call it 'production'. I'm prototyping experimental number systems for high-performance computing and my supervisor has been doing it in mathematica to date, which is so glacial it's unacceptable. Took hours to do a calculation that julia can do in seconds.