All of Nathan2's Comments + Replies

Consider how this could be tested. One would write a program that generates a virtual rubik's cube, and passes this on to the AI to be solved (this avoids the complexity of first having to learn how to control robotic hands). It can't just randomly assign colours to sides, lest it end up with an unsolveable cube. Hence, the preparatory program starts with a solved cube, and then applies a random sequence of moves to it. This will almost certainly be done on the same computer as the AI is running on. A good AI, therefore, should be able to learn to inspect its own working memory, and observe other running threads on the system - it will simply observe the moves used to shuffle the cube, and can then easily reverse them if asked. It is possible, of course, for test conditions to be altered to avoid this solution. That would, I think, be a mistake - the AI will be able to learn a lot from inspecting its own running processes (combined with the research that led to its development), and this behaviour should (in a known Friendly AI) be encouraged.

I had the same problem. I think it would need some genetic algorithm in order to figure out about how "close" it is to the solution, then make a tree structure where it figures out what happens after every combination of however many moves, and it does the one that looks closest to the solution. It would update the algorithm based on how close it is to the closest solution. For example, if it's five moves away from something that looks about 37 moves away from finishing, then it's about 42 moves away now. The problem with this is that when you start it, it will have no idea how close anything is to the solution except for the solution, and there's no way it's getting to that by chance. Essentially, you'd have to cheat and start by giving it almost solved Rubik's cubes, and slowly giving it more randomized ones. It won't learn on its own, but you can teach it pretty easily.