OCELL/CPLL a 2-gen friendly alternative to COLL/EPLL

Discussion in 'General Speedcubing Discussion' started by Cride5, Oct 9, 2009.

Welcome to the Speedsolving.com. You are currently viewing our boards as a guest which gives you limited access to join discussions and access our other features. By joining our free community of over 30,000 people, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so please, join our community today!

If you have any problems with the registration process or your account login, please contact us and we'll help you get started. We look forward to seeing you on the forums!

Already a member? Login to stop seeing this message.
  1. Cride5

    Cride5 Premium Member

    Jan 27, 2009
    This is an alternative system for completing the last layer with edges pre-oriented. Suitable for ZZ, Petrus, VH or ZBF2L users. OCELL stands for: Orient Corners [permute] Edges Last Layer. It could also be called OCEPLL, but that would be a bit of a mouthfull :rolleyes:

    The system is designed to do most of the work with 2-gen algorithms. Since edge permutation and corner orientation can both be solved 2-gen, combining them also can. It does it with a surprisingly low move count, when compared to COLL (the most similar alternative). I've generated all the 2-Gen algorithms for the system and calculated the move count statistics. Doing it non 2-gen is perfectly possible but takes away the system's principal advantage. After OCELL its CPLL (corner permute last layer). ~67% of the cases are A-perm, the rest are H-perm and E-perm, with a 1 in 12 chance of CPLL skip.

    Case Recognition

    The main issue with this method is recognition. Initial recognition of OCLL is extremely easy, but recognition of edge permutation is a little more challenging. The method I use is:

    Look at two opposite edges, are they opposite colours?

    • IF YES: its either SOLVED or OPPOSITE SWAP
      Differentiating between solved, or opposite swap simply involves looking at any two adjacent edges. If they are positioned correctly relative to each other then its the SOLVED case, otherwise SWAP

    • IF NO: Then there are 1 of 4 adjacent swap cases to choose from. First find two adjacent edges of opposite colour (the adjacent edges diagonally opposite will also have opposite colours). If your opposite coloured adjacent edges are in BL and FR then either UF/UL or UB/UR will need to be swapped, otherwise the swap will take place between either UB/UL or UF/UR.

      To choose between the two options look at two opposite coloured edges of your choice, and then the non opposite coloured edge adjacent to each one. If they are correct relative to each other then its the other two which need swapped
    ... its a bit of a long winded explanation, but hopefully it makes sense!

    2-Gen Algorithms

    All move counts are FTM.

    H (on side):
    Solved 15 - R U R' U R U2 R' U' R' U2 R U R' U R
    UF/UB: 13 - (y) R U2 R2 U2 R' U2 R U2 R' U2 R2 U2 R
    UF/UL: 11 - (y) R' U2 R U R' U' R U R' U R
    UF/UR: 11 - R U R' U R U' R' U R U2 R'
    Avg: 12.0

    Solved 15 - R U R2 U' R2 U' R2 U2 R2 U' R' U R U2 R'
    . . . . . 15 - R U2 R2 U' R' U R2 U' R' U' R' U2 R' U2 R
    UF/UB: 13 - R U R' U' R' U2 R U R' U R2 U2 R'
    UF/UL: 13 - (y) R U R' U R U2 R2 U2 R U R' U R
    UB/UL: 13 - (y) R U2 R' U' R U' R2 U' R U' R' U2 R
    . . . . . 13 - (y') R' U' R U' R' U2 R2 U2 R' U' R U' R'
    UF/UR: 9 - R U2 R2 U' R2 U' R2 U2 R
    UB/UR: 9 - R' U2 R2 U R2 U R2 U2 R'
    Avg: 12.0

    Solved 15 - (y) R2 U R U' R U R2 U' R2 U' R' U R' U' R2
    UF/UB: 13 - R' U' R U' R' U2 R2 U R' U R U2 R'
    UF/UL: 15 - R U2 R' U2 R2 U R' U R' U' R U R U2 R2
    UB/UL: 13 - (y2) R U R' U R' U2 R2 U R2 U R2 U' R'
    UF/UR: 15 - (y) R U' R U' R2 U2 R2 U R U' R2 U' R U2 R
    UB/UR: 13 - R' U' R U' R U2 R2 U' R2 U' R2 U R
    Avg: 14.0

    Solved 15 - R U R' U R U2 R' U2 R' U' R U' R' U2 R
    UF/UB: 13 - (y) R U2 R' U' R U' R2 U2 R U R' U R
    UF/UL: 13 - R' U' R2 U R2 U R2 U2 R' U R' U R
    UB/UL: 13 - R U R2 U' R2 U' R2 U2 R U' R U' R'
    UF/UR: 15 - R U R' U' R2 U2 R' U R' U2 R U2 R U R2
    UB/UR: 15 - R' U' R U R2 U2 R U' R U2 R' U2 R' U' R2
    Avg: 14.0

    Solved 15 - R U R' U R U' R' U R U' R' U R U2 R'
    UF/UB: 15 - (y) R' U2 R U R' U R U2 R' U' R U' R' U2 R
    UF/UL: 15 - R2 U R' U R' U2 R' U' R' U R2 U R U' R2
    UB/UL: 15 - R U' R2 U R U2 R2 U R U2 R U2 R U' R2
    UF/UR: 15 - (y) R U' R U' R2 U2 R2 U R U' R2 U' R U2 R
    UB/UR: 15 - R U R2 U' R2 U' R U2 R U2 R' U2 R2 U2 R
    Avg: 15.0

    Solved 11 - R U R' U R' U' R2 U' R2 U2 R
    UF/UB: 13 - (y') R U2 R2 U' R' U' R' U R U R2 U' R'
    UF/UL: 7 - (y') R U2 R' U' R U' R'
    UB/UL: 13 - (y') R2 U' R' U R U R' U2 R' U R2 U R2
    UF/UR: 7 - (y2) R' U' R U' R' U2 R
    UB/UR: 11 - (y2) R U2 R2 U2 R2 U R2 U R2 U' R'
    Avg: 10.33

    Solved 11 - (y2) R' U' R U' R U R2 U R2 U2 R'
    UF/UB: 13 - R U R' U R2 U R U R2 U' R' U' R2
    UF/UL: 7 - R U R' U R U2 R'
    UB/UL: 11 - R' U2 R2 U2 R2 U' R2 U' R2 U R
    UF/UR: 7 - (y') R' U2 R U R' U R
    UB/UR: 13 - R2 U' R2 U' R U R2 U' R2 U R' U R2
    . . . . . 13 - (y') R2 U R U' R' U' R U2 R U' R2 U' R2
    Avg: 10.33

    Total cases: 40

    Move Count

    Remember this is using only 2-gen algs for OCELL. The average optimal move count will be lower without these restrictions.

    Case | Moves | Prob Occurance
    H | 12 | 2/27
    Pi | 12 | 4/27
    Hlight| 14 | 4/27
    T | 14 | 4/27
    Bowtie| 15 | 4/27
    A-Sune| 10.33 | 4/27
    Sune | 10.33 | 4/27
    Solved| 10 | 1/27

    Avg moves = (6*12 + 8*14 + 4*15 + 8*10.33 + 10)/27 ~= 12.47

    Case | Moves | Prob Occurance
    A(a) | 9 | 4/12
    A(b) | 9 | 4/12
    E | 14 | 2/12
    H | 10 | 1/12
    Solved | 0 | 1/12

    Avg moves = (9*4*2 + 14*2 + 10)/12 ~= 9.17

    To calculate average move counts the number of EP cases was counted as follows:
    Total: 4! = 24, broken dowin into:
    Solved: 4/24
    Opposite Swap: 4/24
    Adjacent Swap: 4 * 4/24 (16/24)

    Total moves for OCELL = (6*12 + 8*14 + 4*15 + 8*10.33 + 10)/27 + (9*4*2 + 14*2 + 10)/12 + 0.75 ~= 22.38
    Last edited: Aug 10, 2010
    Pyjam likes this.
  2. miniGOINGS

    miniGOINGS Member

    Feb 27, 2009
    Haha, I've been waiting for this!
  3. blah

    blah brah

    Dec 30, 2007
    A : E : H : CPLL skip = U : Z : H : EPLL skip = 8 : 2 : 1 : 1

    I only see <R,U> 2-gen as an advantage in OH and big cubes.


    And why don't you use phasing to make recognition MUCH easier? You never have to do a cube tilts/rotations for recognition, i.e. two faces suffice.

    Why do you ever have to do a y2 rotation? A z rotation is much faster. Edit: Oh, wait, I forgot the magical technique called AUF.
    Last edited: Oct 9, 2009
  4. Cride5

    Cride5 Premium Member

    Jan 27, 2009
    What are you getting at??

    Phasing could be an option, but it is an extra recognition step with extra moves, and requires a view of 3 sides. I'm not sure if it would actually be quicker :/
    Last edited: Oct 9, 2009
  5. StachuK1992

    StachuK1992 statue

    Jul 24, 2008
    West Chester, PA
    Cride. Use courier new to do the chart, so it actually looks nice.
    Also, why this as opposed to COLL?
  6. LarsN

    LarsN Member

    Aug 7, 2007
    Hvalsø, Denmark
    Your OCEPLL algs are nearly 2 moves longer than avg COLL (OCEPLL: 12.10 / COLL: 10.18) source: http://cubewhiz.com/coll.html

    And I'd take EPLL over CPLL any day. Because they are 2-gen, which you yourself state the importance of.

    But good job finding all the algorithms and making this guide :)
  7. ErikJ

    ErikJ Member

    Mar 23, 2008
    I don't see any advantages of this.
  8. fanwuq

    fanwuq Member

    Dec 5, 2007
  9. Cride5

    Cride5 Premium Member

    Jan 27, 2009
    Thanks :)

    With regards to move count:
    COLL: 9.78 (source: http://www.ai.univ-paris8.fr/~bh/cube/)
    EPLL: 8.75
    2G EPLL: 10.75
    AUF: 0.75
    COLL/EPLL: 19.28
    COLL/2G-EPLL: 21.28

    (see above for explanation)
    Total: 22.38

    Using optimal algs for COLL/EPLL gives a move count advantage of 2.73 over using 2G OCELL. If 2-gen algs are used for EPLL, then the move-count advantage is only 0.73. I haven't generated optimal algs for OCELL but I'd imagine the total move count wouldn't be a huge amount more than COLL.

    The rationale behind using this method, however, is not to lower move counts. As we all know the order of about 20 moves can be significantly quicker if they are 2Gen. The problem with COLL is that its not 2-gen and some of the algs suffer as a result. Although its not 2G, CPLL is very quick, and easily comparable in speed to EPLL, however I'd argue that 2G OCELL could be executed faster than COLL by a competent speedcuber. The main problem (in my opinion) lies in the recognition...

    Interesting, I don't know how I missed that! :eek:
    I personally don't mind E perm, for me its about the same speed as Z. They also occur with the same probability in their respective sets.
    I've not learned COLL so can't comment on how nice the algs are for me personally, but I've deffo heard bad things about them from other COLL users..
    Last edited: Aug 10, 2010
  10. fanwuq

    fanwuq Member

    Dec 5, 2007
    Thank you. That's it. OCELL is bad recognition. E perm is bad recognition and execution. A perms require rotation before execution. COLLs are fairly easy to recognize and execute and EPLLs are just awesome.
  11. qqwref

    qqwref Member

    Dec 18, 2007
    a <script> tag near you
    Yeah, 2GLL is tough to recognize (especially if CP is not solved, because then you either have to recognize CP or look at 3 edges) and CPLL really isn't all that nice. U perms are way faster than A perms (especially for OH) and Z perm is waaaay nicer than E perm. I think overall this is not such a good strategy unless you do CP before 2GLL (but recognition is tough for that too, perhaps you could do CP while inserting the last F2L pair).
  12. Weston

    Weston Premium Member

    May 22, 2009
    I posted a thread on this a couple of weeks ago.
    It's an interesting idea, but not practical.
  13. Lofty

    Lofty Member

    Jun 4, 2007
    Gainesville, Florida
    Well for OH, I have generated LUR COLL but I don't use half of them because they are nasty algs. I'm confident I could take the time to find better algs if I wanted to tho. Maybe you have convinced me to do that if I ever have time. I don't think I'll have time tho.
    A is actually really easy to execute OH. Even still it doesn't compare to U perms. Nothing can compare to U for OH its my fastest alg by almost a second. And E for OH? Bad idea!
  14. Escher

    Escher Babby

    Jul 23, 2008
    Good for learning and practicing 2GLL recognition (and for use in RUgen solving).
    Probably bad for using all the time.

    As a sidenote, my A perms are actually barely slower than my U perms and much more consistent.
  15. Through all the negative comments on this idea, people have failed to point out something very important (though what I find important often isn't for others). Remember that COLL is considered the stepping stone to ZBLL. The problem is, corner permutation recognition is much easier than edge permutation recognition for OLLs.

    I've been thinking of this for a while, since June-ish. Shouldn't there be 2 stepping stones to ZB? Step one - get good at recognizing corners. Step 2 - get good at recognizing edges. Step 3 - don't worry about recognition and just learn algs.

    And so, I think Cride's idea is brilliant, though probably not as a solving method I would use (though 2-gen is a bonus...). I would, and probably will, use this as a step towards learning full ZBLL.

    For all you guys complaining about E perms, find a better alg or something because E perms really aren't that bad, though I will agree that edge algs are nicer.

    Keep up the good work Cride!
  16. 4Chan

    4Chan Premium Member

    Jun 21, 2008
    Zeee Beee Elll Elll?

    Yes, I agree with east amazon to an extent.
    But after the first month, it gets easier to recognize edge permutations.

    I disagree with learning ZBLL in that order, I prefer to learn subset by subset, rather than COLL then OCELL, and then the rest. But thats a personal thing. d:
  17. miniGOINGS

    miniGOINGS Member

    Feb 27, 2009
    This and that other post got me thinking about if the edges weren't preoriented. Instead of OLL/PLL or CLL/ELL what about:

    1. Edge permutation and corner orientation then edge orientation and corner permutation


    2. Corner permutation and edge orientation then corner orientation and edge permutation

    and it seems that the recog is bad for both of them.
  18. Cride5

    Cride5 Premium Member

    Jan 27, 2009
    Cheers for the positive feedback :)

    I'm not sure if people have fully understood the recognition of edge permutation in OCELL. Its not the same as ZBLL edge recognition, because edge permutation does not need to be solved relative to the corners. Instead of 3 cycles and double edge swaps, there are only opposite/adjacent single edge swaps. This simplifies recognition quite a bit, when compared to ZBLL edge recognition. I'll illustrate by showing an OCELL case, and the corresponding ZBLL cases with correctly permuted corners:

    OCELL CASE: Pi with adjacent edge swap in UF/UR

    ZBLL CASE: Pi with corners correctly oriented, Clockwise edge cycle between UL UB and UR

    ZBLL CASE: Pi with corners correctly oriented, Anti clockwise edge cycle between UB, UL and UF

    Looking at only the edges (ie. as OCELL) all these cases are exactly the same, but as ZBLL they are different, because the edge permutation is taken relative to the corners.

    EDIT: As far as I'm aware most ZBLL users first recognise the COLL case, and then the edge permutation case relative to COLL. This issue of edge recognition brings up an interesting possible alternative for ZBLL recognition. First the OCELL case could be recognised, and then corner permutation would be viewed relative to OCELL. This would not be like COLL, so in the examples above:

    The first ZBLL case would be recognised as an adjacent edge swap in UF/UR, then all four corners requiring an anti-clockwise rotation.

    The second case would be recognised as an adjacent edge swap in UF/UR (as before), but this time with all four corners requiring a clockwise rotation.
    Last edited: Oct 10, 2009
  19. 4Chan

    4Chan Premium Member

    Jun 21, 2008
    Very interesting!
    I have never heard of this kind of recognition for ZBLL!
    I've heard of using blocks of color, and dan harris' system, but never this.

    I know the ZBLL set for Pi, and it's a great set. I noticed that we recognize Pi differently.

    Perhaps im just too used to COLL+EdgePermutation recognition, but I can see the potential in this!

    Just wait until I finish ZBLL and start a revolution, and everyone starts to learn ZB! (I dont think many people will follow though)
  20. I would quote the last 2 posts, but that's way to much writing.

    @Cride: I realize the recognition is different for OCELL and ZBLL, but my point was that this could be used just to get familiar with recognizing edges. COLL recognition was the tough part for me, not memorizing the algs. Getting used to seeing pieces differently was what I had to practice.

    @Cubes=Life: Keep up the work with ZBLL. If I were faster (25 seconds doesn't cut it when you're trying to take on full ZB), I would certainly be creating my own ZB algs, but I believe that ZB is truly a sub-20 or even sub-15 method simply because at that point you can truly say you have a dedication to cubing. If you want help generating algs, testing algs (keep in mind my speed here), or creating a page with all the algs on it (not good at websites, but I do make a mean cheat sheet), or anything else in between, just let me know. My ultimate goal has been ZB since I tried COLL about 2 months ago. I'm willing to do a fair bit of work to make a complete set of speedsolving ZB algs.

Share This Page