This post is the first of a number of posts Im going to make about some computer analyses Ive done on the ZZ speedcubing method.
The ZZ method for speedsolving the Rubiks Cube could well be the next mainstream speedcubing method. However as it stands, its still rather underdeveloped and a lot of questions still need to be answered.
The goal of the first analysis, that Im going to cover in this article, is to find the optimal solution length for all possible F2L cases after solving EOLine.
Just to clarify what were trying to do here: all the edges are already oriented (EO) and the DF and DB edges are in their correct position (this is the Line). We now want to solve the remainder of the first two layers using just R, U and L moves.
|From EOLine to F2L|
There are 4 corners and 6 edges involved in this step. The 4 corners can each be oriented in 3 ways and can be placed in 8 positions. The 6 edges have a fixed orientation and can be placed in 10 positions. This means the total number of distinct configurations for solving the first two layers is 34 x (8 x 7 x 6 x 5) x (10 x 9 x 8 x 7 x 6 x 5) = 20,575,296,000.
For each case we want to work out what the shortest solution is and this will tell us what the average and maximum number of moves is for completing this step optimally. Ive written a computer program to do this but I wont go into the details of how it works - at least not in this post - and Ill just present the results.
*Quarter turn metric using only R, U and L|
Some interesting observations:
- The weighted average is 15.64 moves.
- 98.59% of the cases have an optimal solution between 13 and 17 moves.
- 42.21% of the cases have an optimal solution of exactly 16 moves.
- The worst case is 19 moves.
Obviously, its near impossible for a human to track 10 pieces and work out a short solution for them all at the same time. However, I still think that the optimal move counts are very relevant and not just a statistic.
A lot of other methods have built-in inefficiencies. Most notably in the Fridrich method, a cross is built as the first step but it gets broken up repeatedly during the subsequent pairing steps, usually around 8 times in total. As a result the move count of a human Fridrich solver is far from optimal.
The block building approach of ZZ means that you almost never have to break up things youve solved so far.
In short, ZZ is designed to be efficient and close to optimal as possible and thats where your ambitions should lie when you go about mastering this method.
The next step
As I said before, its not practically feasible to solve the F2L in one giant step. We need to break it up in smaller substeps while trying to maintain a good move count and avoiding inducing too much overhead.
In the following posts, I will highlight several strategies for solving ZZF2L that break up the process in different ways and finally compare them against each other.