YruRU Method


pEO Extension


2-gen Finish

Movecount: 45 - 55

Average non-[r, R, U] moves: 5

Algorithms: 84

While fidgeting around with the cube in April 2020, I found myself doing the [R, U, r, u] moveset really quick one handed, so quite naturally I wondered if there was a way to solve the cube using only these moves after some reduction. It was fairly obvious that the 1x1x3 bar in the bottom needed to be solved, since these moves didn't affect it. But only one-sixth of the cases with the 1x1x3 bar were solvable using this moveset, since something called corner permutation needed to be fixed. This was the challenge, to fix corner permutation in inspection.

If you're coming from the CP-line page, you know that it's quite a complicated matter. I started drawing graphs and weirdly labelling things to make sense of the patterns; it took quite a lot of time for me to figure out a way to identify and solve corner permutation just by looking at a scrambled state, and even longer to figure out a way quick enough to consistently fit in the 15 second inspection while keeping it flexible enough to allow the simultaneous solving of CP-line.

And so was born YruRU, or Yash's r-u-R-U reduction. Initially, I only meant to call this CP-line step YruRU, since this is where the cube is being reduced; but once you think about it, there is just one obvious way to move forward. Out of the 4 moves, R, U, r and u, the worst one by far is u, since it disbalances the cube quite a bit. Thus we need to get rid of that as soon as possible. And it turns out it is quite easy to do so, simply by extending it to a 1x2x3. Once we do that, the cube is solvable using only [r, R, U]; no complicated things similar to corner permutation show up in this case.

Now, there are two obvious ways to continue, simply trying to reduce the moveset further. First, we know R-U turning can be really quick one-handed. The way to do this reduction is to extend the 1x2x3 to a 2x2x3, although this time this isn't enough, and we also simultaneously need to do edge orientation. The second way is to reduce the moveset to M-U, i.e. continue like Roux and make a second block; but since CMLL will only be 7 algorithms, we can combine CMLL with second block. This requires 108 algorithms (54 if we are allowed to do M moves before commencing the algorithm) which are all short and [r, R, U]-gen (There is also a third, rather unnatural approach which requires ~500 [r, R, U] algorithms, the lack of symmetry and high algorithm count make me not consider it for now). I tested out both approaches by generating all algorithms, and developed both ideas, till I came across a way to do partial edge orientation during the extension of 1x1x3 to 1x2x3. Also, the extension when applied all by itself is quite inefficient. Thus, unless there was a way to plan CP and FB both in inspection, I concluded that the second approach would not work as good as the first one. So, by simply figuring out a way to do CP-line, we have basically the entire method down. Hence I decided to name the entire method YruRU, since after the first step we simply follow the optimal way of getting things done, a trivial path to figure out. The second approach, I named YRoux, because it sounds similar enough and it essentially borrows from Roux.

Whether YruRU will some day be the go-to OH method or not is up for debate, though it certainly is more efficient than CFOP, less intuition-reliant than Roux, and by far the most ergonomic and TPS-friendly method out there.

- Yash Mehta