@breznak That sounds like a good idea. I've been chatting to Tom over on SO as he's using your current commits and is getting errors. Have a look here http://stackoverflow.com/q/19946949/2969741 and see my answer.

On your PS, your current work is a convenience pattern for handling multiple fields together, where you don't want the bother of creating an entry in description.py for each of the values (e.g. if you have 6 temperature sensors in a building, you want to treat the 6 as a block of identical data streams), but you retain their individuality by respecting their order in the vector. Inside your MultiEncoder you're really feeding a vector of Encoders with a vector of values and producing a big vector of bits for the CLA.
If you want to encode a set of values, this would be an entirely different concept with very different semantics. In this case the encoding would have on-bits representing the presence or absence of a value in the encoded range. This would be akin to OR-ing the encodings of the individual values (or presenting the CLA with all the values simultaneously). You could do this but there's a new problem - the encoding will be much less sparse than a traditional ScalarEncoder produces (21/128 bits). You might need to renormalise the encoding so it has constant sparseness (you might also widen the width of the encoder output as well as cutting down the bits). Interesting work, in any case, and you already have a client!