Recently, I thought about what a method where you only need to know one algorithm would look like for the 2x2. Before inevitably seeing if anyone on this forum had made a solution, I tried to come up with my own. I later found out that no one else had tackled this problem with the 2x2, and instead tried doing this with the much more complicated 3x3, which led to borderline unusable methods which didn't at all translate to learning other methods like CFOP (to be fair, this post was merely taking it as a fun challenge, while the other one was proposing a serious beginner's method).
This 2x2 solution, however, is somewhat feasible for an absolute beginner to use, with the steps translating directly to Ortega if the solver wishes to graduate to that method. To prove that first point, my description of the method will be in such non-technical terms that almost anyone could understand it (along with some beginner-geared modifications, such as prioritizing rotations over U moves), given they know the algorithm, which is simply this:
I'll explain why I chose this algorithm after this tutorial, along with sharing some average move count statistics I calculated.
Now to why I chose this alg. Obviously I couldn't use a PLL alg, because then OLL would HAVE to include some awkward, hard to remember rotations to jumble up the order and hopefully get them oriented. Then, unless I wanted to base this off another method, or even start from absolute zero, I had to use an OLL alg. I couldn't use any 2-gen algs, since that would make PBL a rotation-filled nightmare, and for some reason, the first non 2-gen OLL that I could think of was that one. But why the AUF?
Originally, there was no AUF. I was playing around with this and noticed that after doing this algorithm only three times in some cases, it would look back to the start position without passing through ANY sunes or antisunes, which would be used to lead into the end case needed to solve OLL. Of course, I could always make a few extra rules like "if this pattern is on top, hold it like this, and if that one is, hold it like that", but I knew that would quickly bloat this method, and it went against my secondary goal of maximum simplicity.
Because of this, I tried out an AUF on my 2x2 which, upon a quick test, produced a long loop of eight cases until it cycled back (leading to a total of nine), passing through four sunes or antisunes on the way. Then, I drew out every 2x2 OLL with every rotation. If I didn't add rotations, I'd be forcing the solver to know all of the correct orientations, which was far too complex for this barebones method. Finally, I chained all of the cases together - I'd start with one case and repeat the alg until I got back to the start, noting down every case I passed through.
There ended up being only three massive loops of nine. The one that held the example I described was good, with evenly distributed sunes and antisunes galore, while the other two had merely two sunes/antisunes in quick succession (with one even having them back to back). This lead to a horrific drought that would led to the solver having to do up to SEVEN algs just to get to a SUNE, which would lead to having to do ANOTHER alg to get to the antisune, then ONE MORE to solve OLL - a grand total of NINE ALGS if you happened to get the "U" OLL in that orientation.
PBL was simpler - all I had to do was find a way to spam the alg (with a minor change, of course, as to not just loop through all of the cases) to get a T perm, since the Y perm could simply be two T perms from two different orientations. In the end, I found that if you did the alg thrice, which led to an antisune, then rotated it correctly (piece on bottom right), and did the alg one more time, you'd get a T perm. Do that for yellow and white, doing it twice for a side if there was a Y perm, and ta-da! The cube is done.
But now for statistics. I won't go into how I calculated them, because it's quite boring - I just averaged everything up. Anyhow, for OLL, you would need an average of around 3.5* algs to solve it. Given the diabolical loop described earlier, I expected it to be higher, but I guess the fact that there were 8 sunes/antisunes evened things out.
PBL was quite simple too. Along with learning that the double adjacent swap PBL occurs 44%** of the time (and subsequently learning a better alg for it), I found that the average number of algs needed was a clean 8. While that one in thirty-six chance of doing SIXTEEN ALGS for the simple, three move opp/opp swap disappointed me, I moved on to summing everything up to get a final movecount.
Adding the counts led to around 11.5 algs for an average solve, with the potential for the 0.1%*** chance 25 ALG SOLUTION (and, of course, the same chance of a 0 alg solution). Multiply that by the length of the alg, and adding 0.75 moves as the average AUF (assuming that the solver does rotations for AUF except at the end of PBL) leads to a final average movecount of...
93 moves (minus making the white face, of course)
So yeah, it's very suboptimal, but it couldn't really get much better. Nonetheless, this was a very fun thing to work on for an afternoon, and I challenge you to find your OWN alg that leads to a lower average movecount. If anyone accepts that task, I'm VERY excited to see what you guys produce.
Feel free to ask any questions, and goodbye.
*95/27
**4 in 9
***1 in 972
This 2x2 solution, however, is somewhat feasible for an absolute beginner to use, with the steps translating directly to Ortega if the solver wishes to graduate to that method. To prove that first point, my description of the method will be in such non-technical terms that almost anyone could understand it (along with some beginner-geared modifications, such as prioritizing rotations over U moves), given they know the algorithm, which is simply this:
Code:
L' U R U' L U R' U
(or R' F R F' R U R' U, if you wish)I'll explain why I chose this algorithm after this tutorial, along with sharing some average move count statistics I calculated.
METHOD
- Intuitively make the white face, then rotate the cube so that you're holding the white at the bottom.
- Repeat the algorithm until there's only one yellow square on the top face of the cube. If there's already only one, skip this step.
- Rotate the cube so that the only yellow square is on the bottom right, making sure that white is still on the bottom, then perform the algorithm.
- If the yellow face isn't solved after that, do step 3 one more time.
- Mind only the yellow pieces (it may be helpful to physically cover the other half of the cube). If the yellow side is solved, skip to step 6. If you see a "bar" (two adjacent pieces have the same colour), hold that "bar" on the front. Otherwise, skip to step 5.
- Perform the algorithm three times, then rotate the cube clockwise so the singular yellow piece is at the bottom right, then execute the algorithm one final time. There's a 20% chance that there will still be a bar after this is completed. If so, return to step 4 until the bar is completely gone and the yellow side is solved.
- Turn the cube around so that the white side is on the top, then return to step 4 and perform the same procedure. Eventually, the cube will be solved.
WHY THIS ALG?
Now to why I chose this alg. Obviously I couldn't use a PLL alg, because then OLL would HAVE to include some awkward, hard to remember rotations to jumble up the order and hopefully get them oriented. Then, unless I wanted to base this off another method, or even start from absolute zero, I had to use an OLL alg. I couldn't use any 2-gen algs, since that would make PBL a rotation-filled nightmare, and for some reason, the first non 2-gen OLL that I could think of was that one. But why the AUF?Originally, there was no AUF. I was playing around with this and noticed that after doing this algorithm only three times in some cases, it would look back to the start position without passing through ANY sunes or antisunes, which would be used to lead into the end case needed to solve OLL. Of course, I could always make a few extra rules like "if this pattern is on top, hold it like this, and if that one is, hold it like that", but I knew that would quickly bloat this method, and it went against my secondary goal of maximum simplicity.
Because of this, I tried out an AUF on my 2x2 which, upon a quick test, produced a long loop of eight cases until it cycled back (leading to a total of nine), passing through four sunes or antisunes on the way. Then, I drew out every 2x2 OLL with every rotation. If I didn't add rotations, I'd be forcing the solver to know all of the correct orientations, which was far too complex for this barebones method. Finally, I chained all of the cases together - I'd start with one case and repeat the alg until I got back to the start, noting down every case I passed through.
There ended up being only three massive loops of nine. The one that held the example I described was good, with evenly distributed sunes and antisunes galore, while the other two had merely two sunes/antisunes in quick succession (with one even having them back to back). This lead to a horrific drought that would led to the solver having to do up to SEVEN algs just to get to a SUNE, which would lead to having to do ANOTHER alg to get to the antisune, then ONE MORE to solve OLL - a grand total of NINE ALGS if you happened to get the "U" OLL in that orientation.
PBL was simpler - all I had to do was find a way to spam the alg (with a minor change, of course, as to not just loop through all of the cases) to get a T perm, since the Y perm could simply be two T perms from two different orientations. In the end, I found that if you did the alg thrice, which led to an antisune, then rotated it correctly (piece on bottom right), and did the alg one more time, you'd get a T perm. Do that for yellow and white, doing it twice for a side if there was a Y perm, and ta-da! The cube is done.
STATISTICS
But now for statistics. I won't go into how I calculated them, because it's quite boring - I just averaged everything up. Anyhow, for OLL, you would need an average of around 3.5* algs to solve it. Given the diabolical loop described earlier, I expected it to be higher, but I guess the fact that there were 8 sunes/antisunes evened things out.PBL was quite simple too. Along with learning that the double adjacent swap PBL occurs 44%** of the time (and subsequently learning a better alg for it), I found that the average number of algs needed was a clean 8. While that one in thirty-six chance of doing SIXTEEN ALGS for the simple, three move opp/opp swap disappointed me, I moved on to summing everything up to get a final movecount.
Adding the counts led to around 11.5 algs for an average solve, with the potential for the 0.1%*** chance 25 ALG SOLUTION (and, of course, the same chance of a 0 alg solution). Multiply that by the length of the alg, and adding 0.75 moves as the average AUF (assuming that the solver does rotations for AUF except at the end of PBL) leads to a final average movecount of...
93 moves (minus making the white face, of course)
So yeah, it's very suboptimal, but it couldn't really get much better. Nonetheless, this was a very fun thing to work on for an afternoon, and I challenge you to find your OWN alg that leads to a lower average movecount. If anyone accepts that task, I'm VERY excited to see what you guys produce.
Feel free to ask any questions, and goodbye.
*95/27
**4 in 9
***1 in 972
Last edited:
