Vault Library

The Vault packet on Hackage by Heinrich Apfelmus is quite cool. Type-safe, persistent storage of arbitrary values!

A vault is a map from keys to values, but the keys are parameterized by the type they return. This allows one to retrieves values from the vault that have any value without specializing the type of things the vault stores. How this works behind the scenes is quite interesting, but basically the keys are what store the values in a sense- they store an IO action of type IO () that stores a value in an IORef when it is run. The key keeps a unique value indicating to the vault which IO action to run, and the IORef that is updated. The is possible through the "scary action at a distance" described here: http://apfelmus.nfshost.com/blog/2011/09/04-vault.html.

I think this may be a good choice to implement a modular evolutionary algorithm framework, since it lets individual components (genetic operators for example) set and retrieve configuration information without having to add their desired configuration to the type of the configuration structure (which otherwise seems inevitable).

Discrete Optimization Course at Coursera

I've just started a Discrete Optimization course on the Coursera website. It looks interesting, and I would like to have a firmer understanding of more traditional optimization, given my interest in biologically inspired optimization algorithms.

I'm also looking at a course on analytic combinatorics. My understanding of combinatorics is weaker than I would like, and my understanding of analysis is much weaker then I would like. I'm hoping a class like that would do me some good.

I am hoping this class provides some topics for this blog. Looks like the first problem they talk about is the knapsack problem.

Haskell, Netwire, Gloss, and Swarms

I've been playing around with the Haskell libraries Netwire and Gloss. They are both very nice- Gloss is an incredibly easy way to get something graphical up and running, and its been easy to integrate it with Netwire to get an FRP style simulation going. I've been playing with swarming mechanics, trying to figure out what makes a good looking swarm (and trying to make sure that swarm looks good even when its doing something like following your mouse cursor).

In case your wondering, my choice of Netwire vs some other library for FRP in Haskell was mostly motivated by it being simple. I understand how it works, and I've not had too much trouble getting something small written with it. I'm not going to comment on how it compares to other libraries in any other way but to say that I found it approachable.

The concept behind the program is that a swarm is a list of boids, each with a position and velocity. The position is the sum of the velocity at each time step, and the velocity is the sum of each acceleration at each time step. The accelerations are produces by operators that are given the current swarm, and produce an acceleration for each individual. For example, the cohesion operation takes the centroid of the positions, and produces an acceleration for each individual in the direction of that centroid. The random operation simply produces random accelerations.

This is admittedly not the easiest way to program this kind of thing, but I like the idea of FRP and I want to incorporate it into something larger. Getting started on something small like this has helped me understand how to use FRP (to specify the value of something over time) and familiarized me with Netwire, the FRP library I'm currently using. Hopefully on a larger scale this approach will pay off by letting the components be more modular (including having local state) and the overall flow of control more clear since it is specified by a single abstraction (a flow network).

Good times are ahead, and I think the time has come to wake this blog up.