..finally! I spent quite some time on it but enjoyed every bit solving it. Along the way I made few surprising discoveries about the puzzle that are intimately tide up to computing.
For instance, pretty soon after I have started I could see that the key problem here is how to find the right block quickly enough. Since the pieces do not have fragments of picture painted on them, the only way to identify the piece is by features of shape. Turns out, even though pieces are misleadingly similar, they could be uniquely described by width, height, type of shape (5+), shape or holes, and shape of arms. In a sense, now this is a computational problem on how to “query” (find) these objects in the most efficient manner possible. Put it this way, we could speed-up the process a little bit:
Alignment — will help to see the differences easier. Analogy in computing would be padding, for example in the low level of filesystem routines to speedup sequential access.
Group by type — no need to do search in all pieces. Search in subset makes it few times faster.
Order by same selected feature — duh.
Least Frequently Used policy — cache eviction policy that is used to speedup access when fast storage is very limited (cache). It is much easier to look and try pieces from say a group of 5 than 40. Think of those 5 really good likely to fit-in pieces as your cache and the rest as a RAM. How this works with this puzzle? Let’s say you have a group of 40 and you a searching among them often to fit a segment of similar pieces. If after each failed try to fit an item you put it in the corner, then eventually you will improve quality of your group by having very similar pieces close together, which in turn will let you query them faster in the future.
it’s all started like this
now we get center. but oh boy, everything else is such a mess
doing a bit of cleaning
well, that was helpful
now we have borders!
more stuff emerges
more alignment, more grouping, more sorting!