Avoiding OLL and PLL parity

Good point, I just do PLL parity if I don't see a PLL case.
Generally, negative recognition is slower than positive recognition. So if you see an F-perm and positively recognise that as an F-perm in 0.3 seconds then great, job done, no need to think further, just execute your F-perm alg. But recognising by process of elimination that your PLL is a parity case takes longer - "I don't recognise that, could be a G-perm but that edge looks wrong, hang on, let me check the back, nope, that's definitely parity".

Corner cases are never affected by parity though so recognising and executing an A- or V-perm (or whatever you prefer) can be done really quickly leaving you with a much easier to recognise EPLL case.

It is of course possible to positively recognise PLL parity just by looking at the edges, but for some reason I find this hard when the corners aren't solved, and besides, 2-look also has the advantage that you don't need to master as many LL algs for bigger cubes - most of my 3x3 PLLs I find much harder to finger trick on 4x4+. No more G-perms :)

I don't quite understand your first step, would you care to elaborate?
Assuming you mean EO, there are two parity cases - either 1 or 3 edges misoriented. When one edge is misoriented, just do your regular parity alg to flip it. When three are misoriented, the "normal" approach would be to flip one so that you now have 2 or 4 edges oriented (or 0 if you really screw it up :)). Then you do a regular OLL, but of course, you don't really know what OLL case you're going to get and it could be a longer one or one that's not big-cube friendly.

However, with a simple 2-move setup, you can make your parity alg flip 3 edges instead, so that after parity you always have all edges oriented. Then you know you'll always get an OCLL case.

Edit:
Mark, you could also combine steps 2 and 3 with COLL, which is a useful alg set to learn. Just a suggestion :)
Indeed, I know 1-2 of the Pi/H cases, but I only have so much memory capacity :)
 
Last edited:
Indeed, I know 1-2 of the Pi/H cases, but I only have so much memory capacity :)
I found the U cases very easy to learn. One is two sunes, one is R2 D' R U2 R' D R U2 R, one is the front/back mirror, one is very similar to R2 D' R U2 R' D R U2 R: it's x R2 D2 R U2 R' D2 R U2 R, and one is R' Y perm R. The other one I use F sexy F' then ELL for; I don't know how to do it as a COLL.
 
Since this has essentially turned into a discussion about how to recognize PLL+PLL parity (thank god), I'll just say that I know every case, and with the exception of O perms, can one-look (2 alg) PLL even if I have parity.
 
Since this has essentially turned into a discussion about how to recognize PLL+PLL parity (thank god), I'll just say that I know every case, and with the exception of O perms, can one-look (2 alg) PLL even if I have parity.

Do you have the list of algorithms anywhere?
 
I found the U cases very easy to learn.
A while ago after I did my OLL move count study, I also looked at COLL and compared move counts of EOLL/COLL/EPLL to OLL/PLL. My conclusion was that the move count was only significantly better in a handful of cases. There are other pros and cons though, like increased chance of PLL skip and the extra look required. (Of course if you're doing ZZ or anything else that pre-orients edges, it's a different question.)

If I get time I will dig out that study and rework it for 4x4. It may well be that it gives enough of an advantage to make more of the cases worthwhile.
 
True. I meant edge parity, sorry. But the video doesn't even explain how to avoid anything! You would assume that since the video said "for cubes 4x4 - 7x7" that he would talk about avoiding edge parity.
I would assume that since the title talks about "OLL and PLL parity" that he would talk about OLL and PLL parity.
Do you have the list of algorithms anywhere?
Parity PLL.doc
 
Back
Top