Well that makes my "how many ways can I arrange an Ikea train set" look pretty lame.<p><a href="http://blog.jgc.org/2010/01/more-fun-with-toys-ikea-lillabo-train.html" rel="nofollow">http://blog.jgc.org/2010/01/more-fun-with-toys-ikea-lillabo-...</a>
It bugged me that the 2-brick possibilities pic in [1] wasn't ordered so I made this <a href="http://i.imgur.com/ShWZnwl.png" rel="nofollow">http://i.imgur.com/ShWZnwl.png</a><p>[1] <a href="http://www.math.ku.dk/~eilers/lego.html" rel="nofollow">http://www.math.ku.dk/~eilers/lego.html</a>
Won't their definition conflict with the rectilinear definition? Specifically, there are distinct rectilinear configurations which are homotopic. With two bricks connected by at corner, there are two rectilinear configurations but both are homotopic. So their method used to count "homotopy equivalence classes which contain at least one rectilinear configuration" would yield a lower number than the previous result. This seems to contradict when the paper says that their definition extends the previous one.
Note: this is not my work, just something I stumbled across.<p>GitHub project is here, including examples of all angles considered:
<a href="https://github.com/LasseD/BrickCounting" rel="nofollow">https://github.com/LasseD/BrickCounting</a>
I've always wanted to make a sorting box that, given any quantity of random Lego Mindstorms parts, sorts the parts into shape/size/purpose bins. A static box, no moving parts but the raw feed.<p>I suppose it will have to be a big box, mathematically.