# Partial Corner Control for COLL/OCLL Users



## Cride5 (Aug 27, 2009)

I've looked into full Winter Variation for orienting LL corners during the final F2L block insertion, but I personally prefer just regular OCLL because the algs and recognition are better. However, not using WV doesn't mean we can't still do something useful during insertion of the last block. Another option is *Partial Corner Control*...

I've seen this idea hinted upon in the context of full OLL to try for a better OLL case, but the general consensus is that edge control gives better OLL cases. See:
http://www.speedsolving.com/forum/showthread.php?t=133

However, if all your LL edges are already oriented, then why not aim for a slightly better COLL/OCLL case? My least favourite OCLL cases are H and Pi, so eliminating them leaves only Sune, A-Sune, Bowtie and T (extremely fast), and the slower Headlights case.

Corner Control Method
So how to do it? Turns out that doing it for insertion of the last slot is _stupidly easy_, and here's how its done:

Assuming you have the completed FR CE-pair in the U layer there are only two possible positions for the U layer when the initial R insertion move is made, the trick is to make sure you chose the right one. Choosing the right one every time will _completely eliminate_ the Pi and H cases 

Imagine the U layer is in one of the possible positions, then look at the orientation of these corners:

 First corner to look at is the UBR corner. If yellow is facing up this is good, because its orientation will be preserved during the insertion.


 Next look at the URF corner. If yellow is on the front face, then this is good, because it will be made to face up during the insertion.


 If none of the U-layer corners can be made to face up using the two rules above, then look at the U-layer corner touching the 1x1x2 block. If its U-colour is facing the opposite direction to the block's D colour, then an R U2 R' will make it face up during insertion.


 Finally, if none of these U-layer corners can be made to face up during the insertion then the final place to look is the DFR corner currently occupying the slot. If the U colour is facing to the right, then position the U-layer for a R U' R' insertion. If the U colour is facing to the front, the position the U-layer for an R U2 R' insertion.

For ease of lookahead it is recommended to first look for corners matching rule 1, then rule 2, then rule 3, then finally rule 4. It is guaranteed that at least one of these rules will apply, to give you at least one oriented corner on the U-layer. It guarantees a complete bypass of the H and Pi cases, simply through smart use of AUF before insertion 


*EDIT:* Forgot to mention, this could be very useful for Petrus/ZZ ZBLL users as well - eliminating a lot of cases!

*EDIT2:* Another benefit: It makes an OCLL skip 2x more likely, from 1 in 27 (3.7%) to 1 in 13.5 (7.4%) 

*EDIT3:* KK, this is the last edit, honest  ...but, playing with this for a while, not only can you skip Pi and H, but you can also manipulate the corners to create your favourite cases such as Sunes, and avoid other cases such as Headlights (its possible to reduce the headlights cases by 50% while still avoiding Pi and H) ... using only an AUF! Think I'm going to enjoy playing with this


----------



## blah (Aug 27, 2009)

Similar idea.

It's a FAIL idea though. But I'm pretty certain there's a lot to be learned reading that. That was one of my very first alternate ending ideas. I'll be honest, it has all the characteristics of failed ideas: Inventor discovers the method, thinks he's a genius, overlooks certain crucial points that makes it fail, tells the whole world about it, insists that the whole world learns it, refuses to take any criticism for it, turns out to be less efficient than Fridrich, idea dies. It'd still a good read if you want to get inspiration for other ideas though.


----------



## blah (Aug 27, 2009)

Cride5 said:


> It guarantees a complete bypass of the H and Pi cases, simply through smart use of AUF before insertion


That's not necessarily a good thing. You're the ZZ guy, ever heard of ZZ-blah? Go look it up 



Cride5 said:


> EDIT: Forgot to mention, this could be very useful for ZBLL users as well - eliminating a lot of cases!


I beg to differ. Most ZBF2L cases are non-intuitive algorithms that don't end with F2L pair insertions.

Besides, you forgot something, disorienting all corners eliminates more cases than orienting them, THAT's ZZ-blah.


----------



## Cride5 (Aug 27, 2009)

This is much more lightweight than Summer Variation. Its only guaranteeing that you won't get the H and Pi OCLL/COLL/ZBLL cases, and only takes an average of 0.5 moves (assuming you always finish with a CE pair in the U-layer).

Both recognition and execution extremely fast and easy, and with enough lookahead will take almost zero extra time from your solve. 0.5 moves is deffo worth no H Pi's


----------



## Cride5 (Aug 27, 2009)

blah said:


> Cride5 said:
> 
> 
> > It guarantees a complete bypass of the H and Pi cases, simply through smart use of AUF before insertion
> ...



Yup, its the opposite of this idea, leave ONLY H and Pi cases, for easier recognition of COLL/ZBLL. However, the move-count/recognition for ZZ-blah, is a lot more/worse than Partial Corner Control.

I've tried a few solves and I certainly wouldn't say its a FAIL idea. Recognition/execution genuinely is really easy! Since I haven't yet tested it out on cases other than CE block in U-layer it may yet prove to have a 'hitch'. Will keep you posted 

EDIT:


blah said:


> Cride5 said:
> 
> 
> > EDIT: Forgot to mention, this could be very useful for ZBLL users as well - eliminating a lot of cases!
> ...


Used in conjunction with ZBF2L it wouldn't work because the number of cases would balloon. What I meant was Petrus or ZZ users opting for ZBLL would find it useful


----------



## blah (Aug 27, 2009)

Oh no no no, you got me completely wrong, I didn't say this was a fail idea at all, I just said mine was 

I would actually like to use partial corner control to disorient all corners (yeah I'm stubborn ), simply because COLL recognition is way better for H and Pi cases, and I'm much more consistent with recognizing and executing COLL algs for those  Especially the H cases, their COLL algs all have about the same length and recognition is really easy too. Besides I love my EPLL algs, they're all <M, U> 

Not that I'm cubing anymore these days though  I'd certainly try it out if I were.


----------



## Cride5 (Aug 27, 2009)

Lol, you gotta love the MUMU 

On closer inspection with other F2L cases, it looks like doing this requires more moves than its worth 

However, I'd say that probably 60 or 70% of my final insertions end in this way (with a CE block in U-layer). If a single AUF (half the time) allows me to avoid Pi/H, I'm certainly not going to let that opportunity pass by. The other nice thing about doing this is that it gets you concentrating more on LL lookahead (never a bad thing)


----------



## Lofty (Aug 27, 2009)

I think this is a nice thing to learn and something good to have in your tool box just to have. Make a whole method out of it? Probably not. Personally I really like the H case (non COLL) and kinda like a few of the Pi case COLL's. But everyone likes a Sune and I know more L COLL's than I do know H. 
Good trick, yes. Good method, no.


----------



## 4Chan (Aug 27, 2009)

Hmmmm, I am interested, however....
I like the H cases of ZBLL. (its one of two cases i know.)

I also dont know ZBf2l, so this is interesting. I might play around with this idea, has potential, at least until i learn more zbf2ls.


----------



## Cride5 (Aug 27, 2009)

Cubes=Life said:


> Hmmmm, I am interested, however....
> I like the H cases of ZBLL. (its one of two cases i know.)
> 
> I also dont know ZBf2l, so this is interesting. I might play around with this idea, has potential, at least until i learn more zbf2ls.



I guess this technique can be viewed as a way of 'influencing' which OCLL/COLL/ZBLL case you end up with. I've investigated and verified its ability to avoid Pi and H, which are my least favourite (from an OCLL perspective), but it could just as easily be used to increase the chances of Pi/H, and it may well be possible to eliminate other OCLL cases all together. Certainly it can be used to prevent an OCLL skip - not that i'd ever want to do that 

Have a play around and see whether it can be used to prevent say headlights, T, or some other case(s) like that...


----------



## mazei (Aug 27, 2009)

But I love H and Pi. And pies too.


----------



## cubeninjaIV (Aug 27, 2009)

its a great idea but i like h and pi also this doesnt work unless your f2l pair is already paired so it wont usually work if you use ZBF2L


----------



## Cride5 (Aug 27, 2009)

OK, so eliminating Pi and H is one example of what can be done using Partial Corner Control. Just to give you all a complete picture of what you can do with this, here's a list of every last slot case, and the two possible OCLL cases which result from each U-face position.

Format
Setup: <alg to set up case> --> *Result of R U' R'* / *Result of R U2 R'*









Setup: L' U2 R U' R' U2 L --> *Bowtie* / *Headlights*







Setup: R U R' --> *Oriented* / *A-Sune* 





Setup: R U' L U' R' U L' U2 --> *Bowtie* / *T* 





Setup: R2 D R' U R D' R2 --> *T* / *Bowtie* 





Setup: R U R' U R U2 R' U2 R U R' --> *A-Sune* / *Sune* 





Setup: R U' R' U2 R U R' U2 R U R' U --> *Headlights* / *Pi* 





Setup: R U R' U R U' R' --> *A-Sune* / *H* 







Setup: R U2 R' U' R U R' U' --> *H* / *Sune* 





Setup: L' U2 R U' L U L' U' R' U2 L --> *Pi* / *T* 





Setup: R' U2 R2 U R2 U R2 U' R' --> *Pi* / *Sune* 





Setup: R' U2 R2 U R2 U R U' --> *A-Sune* / *Pi* 





Setup: L U' L' U2 R L U' L' U2 R' --> *T* / *Pi* 





Setup: R' U2 R U R' U R2 U2 R' U' --> *Headlights* / *A-Sune* 





Setup: R U2 L' U R' U' L U' --> *Sune* / *Bowtie* 





Setup: L' R U R' U' L U --> *T* / *A-Sune* 





Setup: R U2 R' L' U R U' R' L U' --> *Headlights* / *Bowtie* 





Setup: R U2 R' U' --> *Sune* / *Oriented* 





Setup: R U R' U' L' U2 R U R' U2 L --> *T* / *T* 





Setup: R U R' U L' R U R' U' L U' --> *Headlights* / *Headlights* 







Setup: L' U' L U' R U' R' L' U2 L --> *Sune* / *Headlights* 





Setup: R' U' R U' R' U2 R2 U R' --> *Sune* / *T* 





Setup: R U2 R D R' U' R D' R2 --> *Bowtie* / *A-Sune* 





Setup: R U' L U' R2 U L' U' R U' --> *Pi* / *Headlights* 





Setup: R U2 R' U' R U R' U' R U R' U' --> *Bowtie* / *H* 





Setup: R' U' R U' R' U2 R2 U2 R' U' --> *Pi* / *Sune* 





Setup: R' U2 R U R' U R2 U R' --> *A-Sune* / *Pi* 





Setup: R U R' U R U' R' U R U' R' --> *H* / *Bowtie* 


So what does it all mean? Well, looking at the data:


 It is impossible to completely eliminate Headlights and T cases, because of cases 18 and 19 where both options produce the same thing.
 Proof of my original theory: No pairs contain both Pi and H cases thus both Pi AND H can be completely eliminated.
 For those who like Pi and H, either of those can be generated 44% of the time, rather than 22%
 For those who like Sune/Anti-Sune, either of those can be generated 55% of the time, rather than 30%
 An OCLL skip can be generated 7.4% of the time, rather than 3.7%
 And so on...
So basically Partial Corner Control can be viewed as a way to 'influence' your OCLL to give you preferred cases.


As well as influencing probability of cases, it can also be used to completely eliminate these groups of cases:

 One of: {Oriented, Bowtie, Sune, Anti-Sune, H, Pi}
 All of: {Pi, H, Oriented} (and subgroups of this)
 All of: {Pi, Bowtie, Oriented} (and subgroups of this)

Looking at Erik's recent F2L video, he's clearly using edge control (where it looks easy) to give a better OLL case. If you already have your edges oriented (ie. ZZ or Petrus users), then why not use a bit of corner control to give you a nicer OCLL, COLL or ZBLL case


----------

