Preface: Maybe you’re sick of reading about all this cubing stuff already, but I’m not, so you’ll have to bear with it. Usual programming will resume eventually.

G perm not included because I still can’t immediately recognise them. For the rest, I did ((alg) y)12 or something similar, to avoid “optimisations” when the first and last moves are the same. Times given are for doing the algorithm 12 times (along with 12 cube rotations). I have no idea how large the standard deviation is, so maybe take that to be around 1.5 seconds. (I *could* do more runs to get the sample standard deviation, but all this speedcubing has been filing my right index fingernail down faster than it grows.)

35.60 |
U perm, cw, ftm/stm-optimal (F2 U M’ U2 M U F2) |

35.18 |
U perm, ccw, ftm/stm-optimal (F2 U’ M’ U2 M U’ F2) |

33.08 |
U perm, cw, stm-optimal, 〈M,U〉 2-gen (M2 U’ M’ U2 M U’ M2) |

35.47 |
U perm, ccw, stm-optimal, 〈M,U〉 2-gen (M2 U M’ U2 M U M2) |

38.77 |
H perm, stm-optimal, 〈M,U〉 2-gen (M2 U M2 U2 M2 U M2) |

43.10 |
H perm, ftm-optimal including AUF (L R U2 L’ R’ y L’ R’ U2 L R) |

45.70 |
H perm, ftm/stm-optimal excluding AUF (R2 S2 R2 U R2 S2 R2) |

44.25 |
Z perm, qtm-optimal (L F U’ R …) |

40.77 |
Z perm, qtm-optimal (F R U R’ …) |

50.63 |
Z perm, ftm/stm-optimal (M S2 M’ D’ M2 u M2) |

41.41 |
A perm, ccw, ftm/stm-optimal (R2 B2 …) |

41.39 |
A perm, cw, ftm/stm-optimal (R’ F R’ …) |

35.16 |
A perm, ccw, ftm/stm-optimal (l’ R’ D2 …) |

36.98 |
A perm, cw, ftm/stm-optimal (l’ U R’ …) |

49.27 |
E perm (l U’ R’ D …) |

45.32 |
F perm (R’ U R U’ R2 …) |

35.84 |
T perm, ftm-optimal, right-handed, 〈U,R,F〉 3-gen (R U R’ U’ …) |

39.03 |
T perm, ftm-optimal, left-handed, 〈U,L,F〉 3-gen (L’ U’ L U …) |

35.81 |
J perm, unflipped, qtm-optimal, 〈L,U,R〉 3-gen (L’ U R …) |

37.95 |
J perm, flipped, qtm-optimal, 〈L,U,R〉 3-gen (R U’ L’ …) |

42.91 |
J perm, unflipped, qtm/ftm-optimal (B2 L U L’ …) |

41.57 |
R perm, ftm-optimal, UBL/UL block (R U2 R’ U2 …) |

40.96 |
R perm, ftm-optimal, UFL/UL block (R’ U2 R U2 …) |

51.40 |
N perm, right block, ftm-optimal, 〈L,U,R〉 3-gen (R U’ L …) |

51.35 |
N perm, left block, ftm-optimal, 〈L,U,R〉 3-gen (L’ U R’ …) |

39.00 |
V perm, ftm-optimal, (R’ U R’ d’ …) |

40.24 |
Y perm (F R U’ R’ …) |

Writing CSS is hard, so deal with this stupid layout. I presume this is quite slow compared to “real” speedcubers, and there are some aberrations like my U perm being the fastest even though it’s not an 〈R,U〉 2-gen algorithm, and all the serious speedcubers seem to swear by 2-gen algorithms. (Note: “2-gen” means it’s in a subgroup generated by two moves.) Cases I know multiple algorithms for have been listed multiple times (U, H, Z, A, T, J) ; there are slight surprises like the standard A perm being slower to execute than my rotated version, but that’s probably because the rotation conjugated with the y-axis rotation I applied after every algorithm simplified to a single z-axis rotation. The net effect is that the average amount of cube rotating in this speed test is less than what a real solve would entail.

(Friendly reminder that in cubing notation, up/down is the y-axis and front/back is the z-axis, just in case Rubik’s cubes weren’t confusing enough.)

Sorting these by speed, it goes like this: U perm (both types), A perm (anticlockwise cycle), J perm (right-handed), T perm, A perm (clockwise cycle), J perm (left-handed), H perm, V perm, Y perm, Z perm, R perm (both types), F perm, E perm, N perm (both types), and finally G perm (all four types).

Well, G perm is only slow now because I still suck at recognising it (and using dumb mnemonics…), but given that it’s the most common PLL (with a 2/9 chance of coming up), I’ll probably get better over time.

The very tiny amount of corner control I exert during corner orientation (by keeping a 2×2 block if it exists) restricts the PLL in special cases to A/J/V, all of which are among the faster ones execution-wise for me, and V also happens to be the rarest. (Probabilities of occurrence are 1/3, 1/3 and 1/6, respectively.) It probably doesn’t make sense to learn all the cases because it’s pretty rare to begin with. Unless I switch to a 2-look/3-look last layer that starts by solving a 2×2 block…

How would that work? I’ve been pondering a bit since I blogged about it. Let’s assume edge orientation is done, as usual. If there are no misoriented corners, go straight to PLL, which can be done in two looks with a bare minimum of {A,U,J,V}, where A, J, V are already needed later on anyway. Otherwise, there is at least one misoriented corner. Picking any such corner as a reference, the two edges that should be adjacent to it can be in 12 possible (relative) locations. This gives a total of 24 cases to learn, or 12 if mirrors aren’t included. Not too big, and I bet most of the cases can be dealt with with a single algorithm applied in different locations.

The next step is a combination of L3C and “L3C plus permutation parity”. The former is well-studied and has 22 cases. As for the latter, the two swapped edges give us a fixed orientation in space, so there are 3^{2}⋅3 = 27 cases. If you exclude mirrors, L3C has 12 cases and L3C+parity has 15 cases. (None of the L3C+parity states are symmetrical, except for the V perm and V perm + diagonally misoriented corners; similarly, in L3C, only the two-corner pure rotation states have reflection symmetry.)

To elaborate a bit on splitting PLL into CPLL and EPLL, H/Z can be done with two U perms (apply *any* U perm, and there will be three wrong edges left). All the diagonal-corner-swap cases can be done with V followed by U; for the Y perm, the only thing to “watch out for” is that this can end with a H perm instead of a U perm if you swap the wrong pair of corners. The adjacent-corner-swap cases can be classified by edge permutation, where F and T have Z-permuted edges (apply any J perm to fix corners), and the rest have U-permuted edges (apply any A perm to fix corners) or correctly-permuted edges (exactly the A perm). (Actually, all the cases in the U-permuted edges category can be handled with the J perm, but the previous sentence gives a one-liner summary that completely avoids special-casing.)

This has net 40 algorithms (not counting mirrors) for a purely 2-look (edge-oriented) last layer. For comparison, OCLL/PLL has net 20 algorithms, also not counting mirrors. Another problem here is probably that recognition of the first half involves finding the two adjacent edges, and since the edges are oriented, their colours won’t be on the U face.

[excised into new post for organisation and readability purposes]

On another note, I had a go at FMC again. (I got sick of failing at BLD.)

Scramble: F2 L2 F2 L2 U B2 D F2 L2 U2 R2 D’ F2 L D L’ D2 L R2 F’ D’ U2

(actually Cube Explorer generated a different scramble, but I screwed up while applying it, so I manually scrambled it some more, then fed it to Cube Explorer to get this)

First attempt (44):

B’ D R2 B’ U2 D2 L2 D (**8**; block)

U’ L U D’ B’ D (**6**; edge orientation)

B2 L’ B2 L2 (**4**; one corner-edge pair)

D B D’ B D B2 D’ (**7**; edge permutation using Sune)

U’ B’ L2 B’ R’ B L2 B’ R B2 (**10**; corner 3-cycle)

D’ B2 D U L R B2 L’ R’ (**9**; H perm)

Second attempt (not counting intermediate attempts that used more moves) (41):

B’ D R2 B’ U2 D2 L2 D (**8**; block)

U’ L U D’ B’ D (**6**; edge orientation)

B2 L’ B2 L2 (**4**; one corner-edge pair)

R B R’ B R B’ R’ B R B2 R’ (**11**; corner orientation using double Sune)

(D L’ D’ L)3 (**12**; corner swaps)

Third attempt (31):

R B2 (**2**; 2×2×2 block with U2 pre-move)

F’ D2 R F’ (**4**; 2×2×3 block)

R D2 R’ D’ R2 D2 R2 U2 (**8**; first two layers and undoing premove)

F L2 B’ L’ B L’ F’ (**7**; edge orientation using wide anti-Sune)

L’ D’ L D’ L D L2 D L2 D2 L’ (**11**; 2GLL using Rune)

This was actually an unusually good run, though I also exceeded the one-hour limit by quite a lot. I’m running a search for the optimal F2L and Cube Explorer’s getting stuck at depth 14, so 14 moves is actually optimal. I didn’t bother trying to fix the bad edges after making the block, because the F2L pieces happened to magically line up and, well, an optimal F2L happened. The last layer part is coincidentally also 14 moves optimal, so there’s a wastage of four moves in my solution. That said, I exhausted all the two-edge-flipping OLLs I knew and the right wide anti-Sune was the only one that left me with a last layer I already knew how to solve optimally.

I don’t have a “very huge” repertoire of last layer algorithms (the edge 3-cycles, some corner 3-cycles, the PLLs, random short OLLs, random 2GLLs, random COLLs, etc.) so this “brute-force through algorithms until something works” technique tends to fail more often than it works. Petrus’s site has a list of forty short-ish ZBLL algorithms such that all edge-oriented last layer cases can be solved with at most two of these algorithms. Sounds kinda useful, but >memorising 40 algorithms. It took me seven years to get around to memorising all of OCLL and PLL, and that’s only 28 algorithms!

Oh, and while I was trying to practise the Roux method, all the blocks just lined up, I switched back to Petrus, and I got a 30-move solve without even backtracking. That probably wasn’t a good scramble.