https://github.com/SergioFierens/ai4r Been on github a long time. I was working on a constraint propagation fork till I got bogged down with work/life.
It's nice to have this available but a lot of AI techniques are fairly computation-intensive. A language like Ruby isn't going to be very efficient for non-trivial datasets.
I think everyone needs to differentiate language, ruby, from implementation, aka the standard mri vm.
The stock mri vm has a gil, and historically, with 1.8, a very naive iterpreter+garbage collector. 1.9.x helps with this, but still suffers performancewise unless you get into massive object creation/etc...
The difference is alternative implementations like jruby+rubinius can drastically shave time off of computation. Much like the difference of CPython to pypy. If however you're overly worried about computational speed and need to have the fastest possible speed bar none, then do the right thing and use c++/java/c. But for exploratory learning or non-time critical computation, why not use a language like Ruby or Python or Lua or whatever?
1) I'm beginning to move into the computational biology field... Your thoughts on using Ruby in this capacity? Its not high frequency trading, but yeah I'd like it to be fast... Is the answer jruby+rubinius?
2) Will learning to program C++ throw off my ruby mojo? Can you speak from the perspective of someone whos fluent in multiple languages?
1) You'd be better off with Python most likely due to library support. (numpy etc...)
2) Why would it? I won't say I'm fluent in c++, but thats mainly due to not having to use it daily. That and I prefer straight c normally, I tend to dig into kernel source and drivers often so c++ isn't a big deal most times.
But don't let language preferences of anyone guide you, evaluate what works best and use it for your problems. I like ruby in general but sometimes python is a better choice, other times perl, other times c, or even shell. Don't optimize code you haven't written yet. Explore the domain with ruby if you want and write a faster version in c once you understand the problem. Or java or whatever.
I'd suggest you start with Python. It's widely used in the ML/AI community and in computational biology so the libraries and documentation are quite good. I'm a big fan of Ruby but it's got a lot of catching up to do here.
I'd leave C++ alone for the time being. Once you've explored the concepts in a simpler, higher-level language you can start to think about making them fast.
All the benchmarks I've seen put JRuby and Rubinius within a factor of 2x or so of 1.9.2 MRI, so you can't count on them to give you a big boost.
But, like you say, there's nothing wrong with using a lighter-weight language to explore. Although Python with numpy/scipy and Matlab/Octave are way ahead here.
True on Jruby/rubinius, its highly dependent on what the code does. I've seen 2x faster runs on rubinius over 1.9.2. And on the other end of the spectrum, I've seen some of my unit tests take over an hour. They take 10 minutes on 1.8.7 on a slow day and cache.
And agree on the python bit, ruby may win for a web language/system administration bits, but python definitely has the leg up with support and use in the sciences.
I haven't actually tried this new Ruby library but numpy/scipy and even more so Matlab are widely used in the ML/AI community. You can find tons of sample code, books, blogs etc that use these tools so it's a lot easier to get started. Numpy is also pretty fast so you may actually get away with pushing your exploratory code into production depending on your scale.
Also, the graphing capabilities of Numpy or Octave can be extremely helpful in exploring your data and figuring out what your code is doing.
I've written C extensions for Ruby and I agree the API is really nice. But a lot of the most useful AI/Machine Learning algorithms involve chunking big data sets through computationally intensive algorithms. This just isn't a strong point for Ruby, C-extension or no.
Premature optimization. If your code runs slowly on larger datasets it'll be easier to write what you need in C then than it will be to guess what you need now.
You probably won't hit a limit, CPUs are fast and even "slow" Ruby can do quite a lot.
If you do hit the limit though, and have exhausted algorithmic improvements, you've got your Ruby as an acceptance test for your C++ which will make it unimaginably easier to write correctly.
If you tried to do it up front you'd blow up the requirements, if you do it after you've profiled your real-world code you may only need a few lines of critical code.
