It's been a long time since I've last pulled out the Raspberry Pi to play with it. I've been watching a lot of videos about Python from PythonProgramming.net, which has been extremely enlightening (though I haven't actually done anything with it). For a short period of time I worked on some programming stuff to try to get some horse racing data, but I just don't have the free time to put into these projects as I would like.
However, I think I found a project that's at an appropriate level for the time that I have. Over the summer, I discovered that my friend's son got interested in speed cubing. I played around with the Rubik's cube a whole lot when I was in high school, and so this discovery piqued my interest a bit. Then this semester I discovered that I had a student that was interested in speed cubing. And I think that put things over the top. So I bought myself a proper speed cube, which arrived in the mail today.
There are basically two aspects of speed cubing. One is just the raw memorization of algorithms to move the pieces to certain places, and the other is the physical technique of manipulating the cube. So my idea is to create a program that's both an algorithm search program as well as an algorithm optimizer. It's true that there are lots of algorithms published on the internet to do all sorts of things. I suspect that those are fairly optimal with regards to the number of moves it takes to execute them. But they may not be optimal with regards to the actual physical manipulation of the cube. For example, RUR' is a very fluid motion, but BUB' is not. I actually think it would be faster to physically rotate the cube and then do RUR' even though the latter is four movements.
So I envision building out this program in steps. I'm going to first build the algorithm search engine, and then I'm going modify that engine so that it takes into account some data about the speed of movements. Or perhaps in the process of finding algorithms, I may discover that there are some moves that I simply need to practice. For example, repeating RUR'U' is a common way to just fiddle around with the cube. And by doing this over and over again, there's a bit of muscle memory that's created to make patterns such as RUR' become more fluid and more automatic. So I might have to just create patterns like that to play with.
This project is somewhat reminiscent of a project I did back in high school. I was frustrated with a permutation game called Triple Cross, and so I programmed a computer to execute a search for an algorithm to solve it. For that game, there were really only four basic motions, so it was a simple tree which made writing the search algorithm easy. The Rubik's Cube has 18 motions, so there will be a much slower search process. However, since computers are significantly faster than they were back in 1998, it's possible that this won't really be an issue. As I'm thinking about potential pitfalls along the way, I'm wondering whether I'll need to make a library of permutations to speed up the search process.
I'm also thinking about developing a display module to show the moves just to get myself used to thinking about the moves using the standard language and notation for speed cubing. If I'm holding a cube in front of me, it's far from natural for me to manipulate it by just reading a string of letters. That display module will probably just come from making drawings using PyGame. It shouldn't be that hard.
No comments:
Post a Comment