# New (?) Edge recognition method (Looking ahead into PLL from OLL)



## ottozing (Feb 28, 2015)

After some chit chat with Chris Olson on facebook about this, I've decided that this method of recognition deserves some form of documentation since apparently I created it, learned it, got decent with it, and never told anyone (oops). The idea is similar to ROLL, so click that if you don't already know what it is. I'm also considering making a write up on ROLL if people feel there's a need for it. Seems like a lot of people don't know what ROLL is really about, and tbh that link I just posted to it doesn't really explain it the way I would like to. anyway, enough background information, onto the actual method. Just a quick warning, this method is pretty much useless to anyone who isn't totally serious about making their last layer as good as possible.

The idea is that during OLL you look at 2 edges. For OLL cases with 2 edges not oriented, you would look at those 2 edges. For dot OLL cases, or OLL cases with all 4 edges oriented, it could be any 2 edges really (Edges closer to the front and right faces of the cube would be preferred I suppose). In my opinion, this method works best for 2 edge OLL's, because dot cases should be uncommon anyway, and all edge LL cases are the hardest to recognize easily due to no edges being mis-oriented. Also, with 2 edge OLL's, the 2 not oriented edges really stand out a lot more, making recognition very straight forward, which I think is how I ended up learning this whole system on accident. The actual rules for this recognition system are as follows.

1. If during OLL you see 2 opposite colour edges and know your OLL alg will solve them as opposites, that means your edges will either be solved or oppositely permuted.
2. If during OLL you see 2 opposite colour edges and *know* your OLL alg *won't* solve them (As in, your OLL alg would solve them as adjacent), then edges will be adjacently permuted.
3. If during OLL you see 2 adjacent colour edges and know your OLL alg usually solves those edges when they are opposites, then edges will be adjacently permuted.
4. If during OLL you see 2 adjacent colour edges and know your OLL alg usually solve those edges when they are adjacent, then it doesn't even matter, it could be any of the 3 possible permutations.

Basically, in order to get good with this system, you need to know how a lot of your OLL algs work (An easy way to check how OLL algs is to just take a solved cube and do the inverse of that OLL alg you want to look at). The actual theory behind this isn't anything too fancy really. It all just stems from the idea that if 2 opposite edges are solved, it can't be an adjacent swap of edges. However, if 2 adjacent edges are solved, then it could be anything. Now, onto some example solves that will hopefully clear up any confusions. I'm only going to be showing OLL cases with 2 edges mis-oriented since as I said before, I feel like those are the cases where the method is really worth it. All of these examples will be done white top green front, with the standard colour scheme. If you use some other weird colour scheme, my explanations will be a tiny bit off. I encourage you all to look at these examples with 2 cubes (You'll see why in a sec).



Spoiler: Example of rule #1



R' U R B U' L' B' U2 R B2 D2 L B2 R2 U2 R' F2 R2 U2

Same OLL as before funnily enough. UR and UL are red and orange respectively (opposite colours). Doing R' F' U' F U' R U R' U R on another cube, you can see UR UL are opposite colours as well. This falls under rule number 1, and the PLL is going to have either solved or oppositely permuted edges after doing the same OLL as before. This rules out 11/21 PLL's, once again without any CP recognition at all.





Spoiler: Example of rule #2



U F' L' U' L F U F' L2 F U2 F' U2 F' L2 F2

Here we have a similar OLL. Notice here UB and UL are red and orange respectively (opposite colours). If you do M U' R U2 R' U' R U' R' M' on another cube, you'll see UB UL are adjacent colours, so this falls under rule number 2, which rules out the possibility of this being any PLL with solved or oppositely permuted edges. That's 9 of the 21 PLL's ruled out, which is somewhat close to half (And this is without taking into account any other possible ways to reduce the possible PLL case using CP style recognition). After doing r' R2 U R' U R U2' R' U M', you can see the PLL is indeed an adjacent edge swap PLL (In this case, a G perm).





Spoiler: Example of rule #3



F U R U' R' F' U B L2 B R2 B' L2 B R2 B2 U2

Here is an easy OLL. UR and UL are red and green respectively (adjacent colours). Doing R' F' U' F U' R U R' U R on another cube, you can see UR UL are opposite colours. Therefore, this falls under rule number 3, and the PLL is going to have adjacently permuted edges (Do R U R' U R U' B U' B' R' and see for yourself).





Spoiler: Example of rule #4



U2 L2 D' R2 F2 L2 U R2 B2 R2 U2 L' D2 R' B' L B' R' U2

Here it's a pretty easy OLL. Just a fat sune. The UR and UF stickers are blue and orange respectively (adjacent colours). If you do r U2 R' U' R U' r' on another cube, you'll see the UR UF colours are also adjacent, meaning this falls under rule number 4, meaning we don't actually get any useful info from this.



If you have any questions about this, let me know. Tell me what you think about this recognition system, and whether you would like to see a similar write up on ROLL.


----------



## PenguinsDontFly (Feb 28, 2015)

I think this is a great idea for further extending the boundaries of speedcubing. Last layer has been somewhat constant for quite a while apart from some last slot stuff and some zbll stuff. Any way to decrease recognition time/ pauses is a great idea. Sadly (at least to this method) I dont use CFOP and cant really try it out or give a sort of first-person opinion. I hope this concept goes really far and eventually we get people one looking last layer and auf predicting the edge perm and corner perm.


----------



## Rubiks560 (Feb 28, 2015)

No one else has commented on this?

Super useful IMO. I've been using it for a few cases.


----------



## PenguinsDontFly (Feb 28, 2015)

Rubiks560 said:


> No one else has commented on this?
> 
> Super useful IMO. I've been using it for a few cases.



IKR!


----------



## Bindedsa (Feb 28, 2015)

I'm definitely going to start using this.


----------



## Akiro (Mar 4, 2015)

Very well written!
I'd be interested in a similar write on ROLL.


----------



## notfeliks (Mar 4, 2015)

I think I have also been using this to some relatively limited extent - just without fully realising it. That probably happened because I have a decent knowledge of when my specific OLL cases will skip PLL or even just do OLLCP. 

Perhaps there is also some way to integrate corner pieces into this. A basic example is the OLL solved by M U (RUR'U') (R'FRF') M' - the case for this which skips PLL has a 1x1x2 bar at URF and UR, and when I see this during a solve I know there will be no E-perm and possibly a PLL skip - obviously not very helpful, but it was a bit basic. Admittedly, trying to use corners intensely with the edges would get a bit crazy, and in the realms of one look last layer, even.

Nice job though.


----------



## ottozing (Mar 4, 2015)

notfeliks said:


> I think I have also been using this to some relatively limited extent - just without fully realising it. That probably happened because I have a decent knowledge of when my specific OLL cases will skip PLL or even just do OLLCP.



I'm not surprised more people have stumbled upon something like this. To me it almost seemed too obvious to warrant a thread, but apparently my way was a lot more codified than anyone else that I've heard about using something like this. I think most people just learned through experience to recognize 2 opposite colour edges on the U layer and know when it'll result in solved or opposite edges. The extension to adjacent U layer stickers isn't quite as obvious, since most people don't realize that knowing where 2 opposite edges are going to be is the key to the whole recognition system.

As for incorporating corners, I'll do a ROLL write-up tonight with examples of both ROLL and ROLL combined with this knew edge recognition system (Which I still need a decent name for). I know that incorporating both of these recognition systems into your solves is fairly reasonable and definitely helpful. When combining both, you'll be surprised how much you can reduce the possible PLL cases you can get. It can get to the point where you know the only possible PLL you can have is a U perm, which is huge compared to not knowing at all what PLL you'll get, and still very nice compared to only knowing it'll be an EPLL.


----------

