This post is the first of a number of posts I’m going to make about some computer analyses I’ve done on the ZZ speedcubing method.

The ZZ method for speedsolving the Rubik’s Cube could well be the next mainstream speedcubing method. However as it stands, it’s still rather underdeveloped and a lot of questions still need to be answered.

The goal of the first analysis, that I’m going to cover in this article, is to find the optimal solution length for all possible F2L cases after solving EOLine.

### God’s algorithm

Just to clarify what we’re 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 3^{4} 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. I’ve written a computer program to do this but I won’t go into the details of how it works - at least not in this post - and I’ll just present the results.

Moves^{*} |
# cases | Distribution | Cummulative |

0 | 1 | <0.01% | <0.01% |

1 | 6 | <0.01% | <0.01% |

2 | 27 | <0.01% | <0.01% |

3 | 135 | <0.01% | <0.01% |

4 | 624 | <0.01% | <0.01% |

5 | 2,963 | <0.01% | <0.01% |

6 | 13,958 | <0.01% | <0.01% |

7 | 65,487 | <0.01% | <0.01% |

8 | 305,078 | <0.01% | <0.01% |

9 | 1,403,488 | 0.01% | 0.01% |

10 | 6,404,528 | 0.03% | 0.04% |

11 | 28,587,553 | 0.14% | 0.18% |

12 | 123,866,634 | 0.60% | 0.78% |

13 | 507,806,834 | 2.47% | 3.25% |

14 | 1,876,501,812 | 9.12% | 12.37% |

15 | 5,443,124,864 | 26.45% | 38.82% |

16 | 8,684,416,076 | 42.21% | 81.03% |

17 | 3,773,928,146 | 18.34% | 99.37% |

18 | 128,854,795 | 0.63% | >99.99% |

19 | 12,991 | <0.01% | 100.00% |

^{*}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**.

### Thoughts

Obviously, it’s 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 you’ve solved so far.

In short, ZZ is designed to be efficient and close to optimal as possible and that’s where your ambitions should lie when you go about mastering this method.

### The next step

As I said before, it’s 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.