## Book's Solution

First let me acknowledge that the RCUBE implementation is the embodiment of James G. Nourse’s work. The conversion to RCUBE notation does not infringe copyright, any more than solving of the puzzle following his instructions is considered stealing of intellectual property. I’ve simply automated the hand-solution.

Sections from the book were translated into sections of RCUBE code. While it would be helpful to quote his words verbatim followed by corresponding code, it was felt that that would indeed violate copyright. Instead, only the RCUBE code is presented along with page number reference for those wishing to follow the solution along in his book.

Major code sections are indicated by comments: ‘Top edges’, ‘Top corners’, ‘Vertical edges’, ‘Bottom corners’ and ‘Bottom edges’. These are self explanatory.

As can be seen from the code the solution gets progressively more complex. The first sections are loops with simple checks and sequences. Towards the end many more checks for colour combinations and patterns are required, as are very long move sequences. This reflects the increased sensitivity to achieved order. Any moves must be accompanied by careful damage repair work.

With the above in mind, and the emphasis on optimizing the performance of moves, it can be shown that algorithms with relatively few logical decisions but possibly more moves actually execute faster than would optimal solutions. Much research has been done to minimize moves by mathematicians and set theorists. The downside is that one ends up with massive look-up tables and complex parity checks to uncover shortcuts. Such background work tends to take much more time than simple turns. Some of the more recent solutions on the Internet will indeed find solutions requiring as few as twenty or so moves. But this is achieved after an hour or more of processing time. RCUBE could solve millions of cubes in that time using sub-optimal means. The choice is yours.

Benchmarks have determined that the Book’s Solution achieves around 1,000,000 turns per second. Ironically this rate is due in part to the presence of long move sequences. If smarter logic were applied, fragmenting the long sequences, the optimizations like ‘transformation vectors’ would be less effective. Transformation vectors refer to an R.I.C. phase in which long sequences of moves are analyzed as to their effects on the cube. A very long sequence may in fact result in only a very small change – perhaps the exchange of two facets. Sequences are replaced by a vector which maps the facet changes. Executing the relatively few facet changes is faster than multiple turns which in isolation involve the movement of twenty (20) facets per turn.

The counter which tracks actual turns or virtual turns replaced by transformation vectors continues to be a valid metric because it is updated by the equivalent amounts. We can turn off transformation processing to prove that the results and counts remain the same.

Below is the calling function to the Book’s Solution. It solves the cube one thousand times to obtain accurate timings. The total number of turns this generates is 210,000 – 210 per solve. The sequence ‘R- T+ R- T+’ scrambles the cube.