• 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!

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

Cride5

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

Pi
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

Headlights
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

T
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

Bowtie
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

Anti-Sune
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

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

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

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

blah

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

Cride5

Premium Member
Joined
Jan 27, 2009
Messages
1,228
Location
Scotland
WCA
2009RIDE01
A : E : H : CPLL skip = U : Z : H : EPLL skip = 8 : 2 : 1 : 1
CPLL:
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

What are you getting at??

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

LarsN

Member
Joined
Aug 7, 2007
Messages
578
Location
Hvalsø, Denmark
WCA
2008NIEL01
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 :)
 

Cride5

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

2G OCELL/CPLL:
(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...

http://www.speedsolving.com/forum/showthread.php?t=15666
I don't like this idea...
I would do anything to just avoid E perms...
There are nothing wrong with COLL algs.
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:

fanwuq

Member
Joined
Dec 5, 2007
Messages
2,831
WCA
2008FANW01
YouTube
Visit Channel
The main problem (in my opinion) lies in the recognition...

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.
 

qqwref

Member
Joined
Dec 18, 2007
Messages
7,834
Location
a <script> tag near you
WCA
2006GOTT01
YouTube
Visit Channel
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).
 

Lofty

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

Escher

Babby
Joined
Jul 23, 2008
Messages
3,374
WCA
2008KINN01
YouTube
Visit Channel
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.
 
Joined
Jan 17, 2009
Messages
377
Location
Portland, OR (where the sun don't shine)
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!
 

4Chan

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

miniGOINGS

Member
Joined
Feb 27, 2009
Messages
3,049
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

~or~

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

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

Cride5

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



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



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



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:

4Chan

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



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



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



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.

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)
 
Joined
Jan 17, 2009
Messages
377
Location
Portland, OR (where the sun don't shine)
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.
 
Top