Hacks from the kitchen

Machine Learning study group in Copenhagen

We just ended the founding meeting of a Machine Learning Study Group here in Copenhagen. We're planning to meet approximately once a month to discuss machine learning algorithms. In between meetings there's a Facebook group where we hang out and discuss our current pet machine learning problems and a Google Docs repository of machine learning resource (still to come).

Here's how we're going to run the group: The goal is to get smarter about machine learning. We're narrowing down on a couple of stacks we care about. Big data using databases - we're going to have a look at Madlib for Postgresql. Or something based on Map/Reduce. Some of us occasionally work in Processing using OpenCV - which is neat, because it's also a good choice on the iPhone/in XCode/Openframeworks.
Some of us are probably going to be looking at Microsoft Solver Foundation in C# at some point. Some of us might be looking at implementing algorithms for one of these environments if no one else has.

We'll be building out our knowledge on configuring and setting up these stacks. The idea is for everyone to work on a pet problem with a machine learning element. We'll share our ideas on how to proceed, share how to approach the stack of software.

The typical approach to a machine learning problems involves

• Identifying the problem - figuring out where machine learning is relevant


• Working out how to get from problem to symbols - i.e. how to turn the data inherent in the problem into input for the textbook algorithms. As an example, in image processing this means coming up with some useful image features to analyze, and figuring out how to compute them efficiently. This can be really tricky, and we expect a lot of the discussions in the group will be about building out our skills in this area.


• Picking the best algorithm - we'll be studying the core algorithms. Not necessarily implementing them; but learning about what they mean - and how they behave

Just to give a little landscape: The founder members are primarily interested in the following spaces of problems: Image analysis - with a little time series analysis of sensor data thrown in for interactive fun - and "big data", running machine learning algorithms on web scala data.

If you're into this problem space, and this style of working - project driven, collaborative and conversational - feel free to join. If there's simply something you'd like to be able to do with a computer, feel free to join as well - maybe one of the more technical hangers on will take an interest in your idea and start working on it.

Leaving perl

So, I was reviewing one of my happiest perl-hacks, the Roskilde band finder, and due to a combination of perl line noise and my own inadequate design I simply failed at extending the hack like I wanted to. That's not what your goto quickfixer tool is supposed to offer you, and so I was disappointed and it felt like I lost some ability right there, as perl refused to be friendly to the task at hand.
I was a bit dismayed, because I have after all done a lot of nice little things with perl, and more so, because of the convenience of habit I have after a decade of perl scripts. I've moved a lot of my scripting to ruby, but ruby fails at delivering the level of brevity I have in perl. Or, ruby used to at least. Lately I've been rethinking that point of view. For sure, I'd rather write Eventmachine servers than POE servers. ActiveRecord outside of Rails isn't so bad. And I just discovered mashup-artist HTTParty. Decide on a "one file only" web framework* and I'm pretty much there.

I still need a couple of niceties** - but I think some DSLy goodness fixes most of what I'm missing. But I'm going to start migrating the Roskilde tool and I'll let you know what it ends up looking like.

* I think just Sinatra with erb will do fine.
** Something that does AWK inside ruby, basically - perl is what does AWK inside perl all on its own.