• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Partial Corner Control for COLL/OCLL Users

Cride5

Premium Member
Joined
Jan 27, 2009
Messages
1,228
Location
Scotland
WCA
2009RIDE01
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:
  1. 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.

  2. 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.

  3. 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.

  4. 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 :D
 
Last edited:

blah

brah
Joined
Dec 30, 2007
Messages
2,139
Location
.
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.
 
Last edited:

blah

brah
Joined
Dec 30, 2007
Messages
2,139
Location
.
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 ;)

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.
 
Last edited:

Cride5

Premium Member
Joined
Jan 27, 2009
Messages
1,228
Location
Scotland
WCA
2009RIDE01
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

Premium Member
Joined
Jan 27, 2009
Messages
1,228
Location
Scotland
WCA
2009RIDE01
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 ;)

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:
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.
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 :p
 
Last edited:

blah

brah
Joined
Dec 30, 2007
Messages
2,139
Location
.
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 :p

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> :D

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

Cride5

Premium Member
Joined
Jan 27, 2009
Messages
1,228
Location
Scotland
WCA
2009RIDE01
Lol, you gotta love the MUMU ;)

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

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

Member
Joined
Jun 4, 2007
Messages
1,583
Location
Gainesville, Florida
WCA
2008LOFT01
YouTube
Visit Channel
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

Premium Member
Joined
Jun 21, 2008
Messages
2,984
Location
Lumbridge
YouTube
Visit Channel
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

Premium Member
Joined
Jan 27, 2009
Messages
1,228
Location
Scotland
WCA
2009RIDE01
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 :p

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

Cride5

Premium Member
Joined
Jan 27, 2009
Messages
1,228
Location
Scotland
WCA
2009RIDE01
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'



  1. f2ll-27.bmp
    Setup: L' U2 R U' R' U2 L --> Bowtie / Headlights


  2. f2ll-21.bmp
    Setup: R U R' --> Oriented / A-Sune
  3. f2ll-22.bmp
    Setup: R U' L U' R' U L' U2 --> Bowtie / T
  4. f2ll-23.bmp
    Setup: R2 D R' U R D' R2 --> T / Bowtie
  5. f2ll-24.bmp
    Setup: R U R' U R U2 R' U2 R U R' --> A-Sune / Sune
  6. f2ll-25.bmp
    Setup: R U' R' U2 R U R' U2 R U R' U --> Headlights / Pi
  7. f2ll-26.bmp
    Setup: R U R' U R U' R' --> A-Sune / H


  8. f2ll-09.bmp
    Setup: R U2 R' U' R U R' U' --> H / Sune
  9. f2ll-10.bmp
    Setup: L' U2 R U' L U L' U' R' U2 L --> Pi / T
  10. f2ll-11.bmp
    Setup: R' U2 R2 U R2 U R2 U' R' --> Pi / Sune
  11. f2ll-12.bmp
    Setup: R' U2 R2 U R2 U R U' --> A-Sune / Pi
  12. f2ll-13.bmp
    Setup: L U' L' U2 R L U' L' U2 R' --> T / Pi
  13. f2ll-14.bmp
    Setup: R' U2 R U R' U R2 U2 R' U' --> Headlights / A-Sune
  14. f2ll-15.bmp
    Setup: R U2 L' U R' U' L U' --> Sune / Bowtie
  15. f2ll-16.bmp
    Setup: L' R U R' U' L U --> T / A-Sune
  16. f2ll-17.bmp
    Setup: R U2 R' L' U R U' R' L U' --> Headlights / Bowtie
  17. f2ll-18.bmp
    Setup: R U2 R' U' --> Sune / Oriented
  18. f2ll-19.bmp
    Setup: R U R' U' L' U2 R U R' U2 L --> T / T
  19. f2ll-20.bmp
    Setup: R U R' U L' R U R' U' L U' --> Headlights / Headlights


  20. f2ll-01.bmp
    Setup: L' U' L U' R U' R' L' U2 L --> Sune / Headlights
  21. f2ll-02.bmp
    Setup: R' U' R U' R' U2 R2 U R' --> Sune / T
  22. f2ll-03.bmp
    Setup: R U2 R D R' U' R D' R2 --> Bowtie / A-Sune
  23. f2ll-04.bmp
    Setup: R U' L U' R2 U L' U' R U' --> Pi / Headlights
  24. f2ll-05.bmp
    Setup: R U2 R' U' R U R' U' R U R' U' --> Bowtie / H
  25. f2ll-06.bmp
    Setup: R' U' R U' R' U2 R2 U2 R' U' --> Pi / Sune
  26. f2ll-07.bmp
    Setup: R' U2 R U R' U R2 U R' --> A-Sune / Pi
  27. f2ll-08.bmp
    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 :)
 
Top