Corners-first (edges-last) method
In the summer of 2004, I started with a solving of the Rubik's cube. Alone and without any help, at first. I came (accidentally, needed to say) to the point in which only 2 edges were misoriented on a cube - see a notation for the Rubik's cube. While trying to solve this problem, I, however, scrambled the cube and didn't come close to this state anymore.
Today, I regret I didn't solve a cube intuitively back then. I found a tutorial on the internet (beginner's method: layer by layer solution) and solved the puzzle accordingly. Even though I used instructions, a Rubik's cube solved for the first time made me feel an indescribable joy (almost as strong as a Rubik's cube solved while blindfolded did for the first time in my case).
Since I am playful and competitive type, I was not only pulled in, but also forced to make faster execution each time. Soon I found out there are faster methods that the one I have been using so far (the term "faster method" is nonsense - methods can not be "fast"). At that time, only the corners-first and CFOP (corners-first is being abbreviated by the letters CF, which can be confused with CFOP, especially by beginners) were possible to be found online in Czech. By the way, it's a pity that neither of Czech sites from which I gathered information in my cube-beginnings (speedcubing.wz.cz (CF) by Jan Balhar, or cube.misto.cz (CFOP) by Josef Jelínek), are existing to this day. Since CFOP contained more algorithms, I picked the CF method.
I spent some time studying it, but I didn't understand it. At least the algorithmic part for solving the edges. Therefore, I adapted it to a form that was understandable to me and which is described below.
There are precisely the algorithms I use. I'm not saying those are the best ones. In fact, I say they could be better ones. Still, on 6. 11. 2010 I reached an average time of 18.94 seconds [16.66 + 2 = 18.66, 21.45, 19.76, 18.71, 17.57, (24.56), 22.27, 17.03, 18.51, (16.20), 19.03, 16.45] with them (and no others) and on 9. 3. 2010 I reached an average time of 3.45 seconds for a 2x2x2 cube. If anyone cares, the 2x2x2 attempts were following:
- 4.12 F R F' U R U' F U R' U2
- 3.21 R F R2 F' R F2 R F U
- 4.64 R U' R F2 U' R' U F2 U2
- 3.21 U' F R' U2 R2 F R' U' F2 U'
- 3.92 U2 R' F U F' U R'
- 4.06 F' U F2 R' F2 R F' U R'
- 3.08 U2 F2 R2 U' R U' F
- (5.09) U' F R' U F U2 F R
- 2.89 R F2 R' U2 F U' R2 F U
- 2.43 U R U' R' U F2 R' F' R U2
- (2.31) R2 U2 R' U2 R' F
- 2.95 R2 F U' F R F' R2 F' R'
Corners-first method experienced the biggest boom during the 80's (a winner of the first world championship used this method, among others). Nowadays there are plenty of variants of CF method, but I know only one person from France who is speedcubing a 3x3x3 Rubik's cube more or less in the same order of steps as described below. The method is often referred to as Ortega (Ortega for a 3x3x3 cube, more precisely), because its first step corresponds to a solving of a 2x2x2 Rubik's cube just by the Ortega method (i.e. the Ortega method is primarily used for a 2x2x2 cube, however, it can be used in some step of a 3x3x3 cube as well). Historically speaking - a 2x2x2 cube was introduced on a market later than a 3x3x3 cube - the Ortega method has been used, at first, just for corners of a 3x3x3 Rubik's cube in the same manner as demonstrated below.
The method can be divided into three main steps:
- solving of corners
- solving of all edges except for those belonging to the M-ring
- solving of edges in the M-ring
Solving of corners
After completing first step, the puzzle might look like this:
But it doesn't have to. Personally, I don't insist on corners to be "solved" (as seen on a picture). I only care whether the lower-layer corners, as well as the upper-layer corners, are correctly permuted and oriented. But I don't care about their relative position at this moment. Thus it doesn't matter if the upper layer on a picture is rotated by a U move, U2 or U3 = U' move, or if corners are "solved" (as in case of a picture).
While solving, I am color-neutral, which I think is a quite considerable advantage. That means I don't care what color (in this case corners) I start with.
Usually I start with an orientation of 4 corners, then I orient 4 opposite corners, and then I permute all corners. The way I achieve it is that during the inspection prior to a solve itself, I choose 4 corners of the same color (since I'm color-neutral, it doesn't matter which ones) which can be fastest placed toward to one center. Orientation of these 4 corners (in case of a color-neutrality) takes 3.97 moves on average, and it is always possible to make it in five moves or less.
I deliberately made a little test with a 2x2x2 cube (which is an equivalent to 3x3x3 corners in first approximation). I scrambled it one hundred times and solved its one face in 15 seconds (it is an inspection time) by the fewest moves. I recorded a number of moves for each attempt. Here are the results:
0 moves needed to solve a face: 0x
1 move needed to solve a face: 6x
2 moves needed to solve a face: 12x
3 moves needed to solve a face: 35x
4 moves needed to solve a face: 37x
5 moves needed to solve a face: 9x
6 moves needed to solve a face: 1x
average: 3.34 moves per a face solve
I was quite surprised by the result because I was expecting higher average value. The reason why the average is so small might be that I scrambled a cube hand-randomly (i.e. not according to the optimal computer solution) in a combination with a fact that once I solved one face, I started to scramble a cube (which I think increases a probability of getting a lower number of moves when solving a face of another color in the next attempt). An attempt for which I needed 6 moves could be solved in fewer moves, but I would need longer time period than 15 seconds.
Commonly, for a 3x3x3 cube, I don't try to orient 4 corners and then place a center piece toward to them. I rather try to place the corners toward to the center most efficiently - preferably already oriented. But it is not a requirement. Simultaneously, I hold the cube so that the oriented corners with the center would be at the bottom (bottom face). The reason is simple: I don't have to rotate with the cube as a whole later, thus I save some time. Then, I orient opposite corners using these algorithms (assuming "white" corners are oriented and placed in the bottom face, and using a so-called BOY color scheme (white opposite yellow, green opposite blue and red opposite orange)).
Orientation of corners |
||
algorithm number |
case |
algorithm |
1 |
R U R' U R U2' R' |
|
2 |
R U2' R' U' R U' R' |
|
3 |
R2 U2' R U2' R2' |
|
4 |
R U' R2' F R2 U' R' |
|
5 |
R2 U R U2 R U2 R |
|
6 |
R U R' y+U' L' U' L |
|
7 |
L U' L' y'+U' R' F R |
After completing an orientation of corners, it will be (mostly) needed to permute them. In conjunction with the following pictures, the algorithms I use can be seen in a table. By a yellow part of a picture are denoted upper face corners, by a white part of a picture are denoted lower face corners. The arrow illustrates which corners are to be swapped (permuted).
Permutation of corners |
||
algorithm number |
case |
algorithm |
8 |
R U2' R' U' R U2' l' U R' U' l |
|
9 |
L U L2 U R U R' U R U L2 U R' |
|
10 |
L2' U' L2' y+U2 L2 U' L2' |
|
11 |
L2' U' L2' U L2 U' L2' U L2 |
|
12 |
R2' F2 R2 |
Some of you might notice that there aren't mentioned all cases for a permutation of corners. Missing is a case in which two diagonal corners in the lower face are needed to be swapped (symmetrical case to a case no. 9), as well as a case in which adjacent corners in the lower face are needed to be swapped (symmetrical case to a case no. 8), or a case in which diagonal corners in the upper face and adjacent corners in the lower face are needed to be swapped (symmetrical case to a case no. 11). It's because I can't solve those mentioned cases algorithmically. Ordinarily in such situation, I rotate the cube as a whole - x2' move - and solve already known case. I guess I am lazy to learn three more algorithms (for a symmetrical case to a case no. 11, I sometimes do r2' instead of initial L2' and then I continue in execution of algorithm). Since I execute some moves better on a 2x2x2 cube rather than on a 3x3x3 cube, I execute an algorithm no. 5 on a 2x2x2 as follows: R2 U R U2' R U2' R. Execution of my other algorithms is the same for both 2x2x2 and 3x3x3 cubes.
The system I use to solve corners is not optimal in any way, and it could be improved, i.e. made faster, by two things. First one is to use a better solving method for a 2x2x2 Rubik's cube. Let CLL, SS or EG (instead of used Ortega) be an example.
Second thing deals with optimizing of algorithms. There are a lot of 2x2x2 algorithms for above stated methods on the internet. For all of them, I was formerly mentioning a Polish database with more than 40 000 algorithms, but in 2018 I wasn't able to find it anymore. If I had to learn the algorithms from a table above again, I would choose another one for a case no. 9, and possibly also for the cases no. 4, 6, 7 and 11.
Solving of corners is the hardest part of a solve, at least in terms of a number of algorithms. I solve all edges except for those belonging to the M-ring intuitively, and to solve edges in the M-ring, I use only a few of algorithms (if those move sequences can be even called that), see below.
Solving of all edges except for those belonging to the M-ring
At this point, I rotate the cube as a whole (by making a z' move) and solve 3 edges which belong to the original upper face (yellow color in this case). Since my corner permutation algorithms are automatized, I am, during its completion, able to track the locations of some edges. Hence I usually come fluently over from a solving of corners to a solving of edges.
An edge which is to be solved can appear in three layers: left one (to which it belongs), middle one (let's denote it as the M-ring) and right one. If an edge to be solved is located in the left layer, I move it to the M-ring (see two left simulators below). If an edge to be solved is located in the M-ring, I always move it to the FD (which is the same as the DF in this case) position and I also move a location to which an edge belongs to the UL = LU position. Then, I continue in a way shown on two middle simulators. If an edge to be solved is initially present in the right layer (face, if you like), I move it to the RU (or, the UR) position and I also move a location to which an edge belongs to the UL = LU position. Then I execute the moves shown on the right simulators.
Once I'm done with solving 3 out of 4 edges in the left face, I rotate the cube as a whole (commonly by z2') and solve all 4 edges in a current left face (i.e. white edges in this case) in the same way. That z2' move is a waste of time (it doesn't have to be done at all - edges can be solved into the right face), but I have a habit to do so. Certainly, an actual solving process of white edges must be done in a way so that the yellow edges, being already solved, wouldn't be scrambled yet. A keyhole (or, working edge), i.e. a location of unsolved yellow edge, serves for this purpose.
I don't rotate the cube after I'm done with solving of fourth white edge. A missing yellow edge can be either in the right layer (in which case I perform the moves shown on the left simulator below) or in the M-ring (see middle one and right simulator below).
When inserting the last white edge (in our case), I look whether it is at the "keyhole" position, i.e. the UR, by any chance. If it is (and if an edge belonging to the UR position is in the M-ring), I usually solve last two edges (white one and yellow one) simultaneously (see the simulators below). But it is not a requirement. It always depends on how quickly I can see both edges. When I don't see one of them almost immediately, I solve last two edges one by one.
Depending on arbitrary occurrence of last two edges on the cube, I'm sometimes able to solve them at once (e.g. if the UR and UL edges need to be swapped, I will execute U' M2' U2 M2 U', or if I am orienting the UL edge and an edge belonging to the UR is at the FD position, I will perform U' M U2' M2' U', or if I am orienting the UR edge and an edge belonging to the UL is at the FD position, I will do U M U2' M2' U). But it is not a rule, and as already mentioned, if it is faster to find one edge first and then the other one, I solve them (even for a price of higher number of moves) in two stages.
As in a case of solving of corners, I can see a number of possible improvements also for a solving of edges which are not in the M-ring. The first one is to solve edges in pairs - two edges at once (something like you can see on the previous 4 simulators and in the last paragraph, but this time for all edges except for those belonging to the M-ring - for example, two edges at the UR and UL positions could be always solved, and R L' moves could be done after their solving is completed, so that the whole process could be then repeated again. The UR + UL edges can be solved relatively easily by placing appropriate edges at the DF and DB positions, one at a time. Then, in response to that procedure, it only remains to execute a U or U' move so that the next M2 move would solve the edges at current DF and DB positions. Now it is only necessary to align just solved edges in their layers (by performing a U or U' move), do e.g. R L' moves and continue in solving of another two edges simultaneously). Another speed-up can be achieved by a solving of last 5 or 6 edges at once (as being done in Waterman or Roux method), or at least by orienting of edges which belong to the M-ring while simultaneously solving the edges not belonging into this ring.
Solving of edges in the M-ring
Finally I "solve" all corners, which means I usually do R and L moves so that only 4 edges in the M-ring are not solved yet.
At this point, there are 21 cases for the remaining edges. 1 of them is for all edges being solved (thus a whole cube will be solved), the other 2 cases are inverse to another ones, so it is needed to learn 18 algorithms in order to solve all 4 edges at once.
I don't know that many, no way. Most commonly, I solve 4 remaining edges in two algorithms, sometimes in one of them (when I know the right algorithm out of 18 possibilities), but there are also cases in which I use three algorithms (that sucks, but that's what I'm getting for being lazy to learn a few extra algorithms).
Now, all algorithms I use are summarized in the following table (for a symmetrical case to no. 15, when the cube is rotated by a y2 move, I use U2' M' U2' M instead of y2 and an algorithm to case no. 15).
Solving of edges in the M-ring |
||
algorithm number |
case |
algorithm |
13 |
U2' M2 U2' M2 |
|
14 |
z' M2 E' M2 E' |
|
15 |
U2' M U2' M' |
|
16 |
M' U M' U M' U2 M U M U M U2' |
|
17 |
y' R2 U M U' R2 U M' U' |
|
18 |
y' U M U' R2 U M' U' R2' |
Solving process of edges in the M-ring can be, of course, speed-up by increasing of a number of algorithms (ideally by learning all 18 of them).
In any case, I don't use more than 15 algorithms learnt by heart. 12 of them are for corners and a couple of them are for edges (cases 13 - 15 don't fit into the "algorithm" definition, since they are 4-movers. A case no. 16 is easy to remember and 17 with 18 are inverse to each other).
What I like about the corners-first method is a price/performance ratio, because sub-19 seconds can be achieved with 15 algorithms. Allow me to paraphrase one (Czech) politician: "ladies and gentlemen, I don't want to offend you, but which of you has it?"
With given solving proposal, I think average times around 16 seconds are a human maximum. I believe it could be lowered to the times around 12 seconds by an implementation of mentioned improvements (more effective solving of corners and edges). Note that Jessica Fridrich herself estimated 11 seconds as a limit for her solving system. Many speedcubers exceeded her estimate by more than 4 seconds.
The page was graphically improved by Michael Feather and Conrad Rider.