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

[Spitfire97]

where do you recognize these cases from?

 

[Cride5]

Optimal move count for OCELL

Decided to calculate the optimal move count for OCELL for a direct comparison with optimal COLL. Here are the algs/results:

H
Solved: 11 - F R2 B2 D2 F L2 B D2 F2 R2 B
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: 11.33

Pi
Solved: 11 - L' F D2 F' L U L' F D2 F' L
UF/UB: 12 - R U B U' B' L R' F U F' U' L'
UF/UL: 11 - R B2 D' R2 U R2 D M' B2 L'
UB/UL: 11 - R' F2 D R2 U' R2 D' M F2 L
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: 10.5

Headlights
Solved: 9 - R2 D R' U2 R D' R' U2 R'
UF/UB: 13 - (y2) R' U' R U' R' U2 R2 U R' U R U2 R'
UF/UL: 9 - R2 D L' B2 L D' R' U2 R'
UB/UL: 10 - (y2) R' U2 R F U' R' U' R U F'
UF/UR: 9 - L2 D' R B2 R' D L U2 L
UB/UR: 10 - (y2) L U2 L' F' U L U L' U' F
Avg: 10

T
Solved 8 - r U R' U' L' U R U'
UF/UB: 10 - (y2) R' F2 D2 B' L' B D2 F' R
UF/UL: 10 - (y2) L' U R B2 U B2 U' B2 M'
UB/UL: 10 - (y2) L U' R' F2 U' F2 U F2 M
UF/UR: 10 - B U L U2 L' U L U L' B'
UB/UR: 10 - F' U' L' U2 L U' L' U' L F
Avg: 9.67

Bowtie
Solved 8 - (y2 x) U R' U' L U R U' r'
UF/UB: 11 - L' B L2 D2 R F R' D2 L B' L2
UF/UL: 9 - R B2 L2 D L D' L B2 R'
UB/UL: 10 - F R U' R' U' R U2 R' U' F'
UF/UR: 9 - (y') L' U2 L' D' R B2 R' D L2
UB/UR: 9 - (r') R' F2 L2 D' L' D L' F2 R
Avg: 9.33

Anti-Sune
Solved 7 - L' U R U' L U R'
UF/UB: 10 - (y) F' U R2 D2 B' L2 D' B D' R2
UF/UL: 7 - (y') R U2 R' U' R U' R'
UB/UL: 10 - (y) L R' D' F2 D R2 U' R' U L'
UF/UR: 7 - (y2) R' U' R U' R' U2 R
UB/UR: 10 - R' U L' U' L2 D F2 D' L' R
Avg: 8.5

Sune
Solved 7 - R U' L' U R' U' L
UF/UB: 10 - R2 D B' D L2 B D2 R2 U' F
UF/UL: 7 - R U R' U R U2 R'
UB/UL: 10 - L U' R U R2 D' F2 D R L'
UF/UR: 7 - (y') R' U2 R U R' U R
UB/UR: 10 - (y') R' L D F2 D' L2 U L U' R
Avg: 8.5


H | 11.33 | 2/27
Pi | 10.5 | 4/27
Hlight| 10 | 4/27
T | 9.67 | 4/27
Bowtie| 9.33 | 4/27
A-Sune| 8.5 | 4/27
Sune | 8.5 | 4/27
Solved| 7.67 | 1/27

Total for OCELL (htm)
= ((11+1/3)*2 + 10.5*4 + 10*4 + (9+2/3)*4 + (9+1/3)*4 + 8.5*8 + 7+2/3)/27
= 9 + 40/81
= 9.49

Total for OCELL+CPLL (htm)
= 9 + 40/81 + 9 + 1/6 + 3/4
= 19.41

So optimal OCELL+CPLL is 0.13 more moves than optimal COLL/EPLL. Although the algs haven't been optimised for fingertricks, some of them feel pretty good 'out of the box'. Given that the minimum move count for a lot of them is so low, there is good scope finding nice finger friendly algs, or in the worst-cases, simply use the RU-gen algs.

OCELL appears to have better algs than COLL, but then EPLL is probably better than CPLL. I think the main downside to OCELL is the edge recognition - mainly because it requires scanning of L+R+F, rather than just two faces. It is theoretically possible to scan EP using only two sides, but it would also require scanning of CP and probably isn't practical. The plus-side to OCELL recog is that it's based on only 3-stickers, so with time could become pretty fast.

 

[irontwig]

Optimal COLL+EPLL in STM is 16.95, though.

 

[qqwref]

H | 11.33 | 2/27
Pi | 10.5 | 4/27
Hlight| 10 | 4/27
T | 9.67 | 4/27
Bowtie| 9.33 | 4/27
A-Sune| 8.5 | 4/27
Sune | 8.5 | 4/27
Solved| 0 | 1/27

Total for OCELL (htm)
= ((11+1/3)*2 + 10.5*4 + 10*4 + (9+2/3)*4 + (9+1/3)*4 + 8.5*8)/27
= 9 + 17/81
= 9.21

Hang on. You're not counting the extra moves required to solve PLL (instead of CPLL) if you got a skipped CO. And, if you're talking about pure OCELL, you'd have to learn CP-ignoring EP algs for this case (just U and T perms thankfully), which would add roughly (7.667 * 1/27) to this figure.

 

[Cride5]

That's a very good point qq! I guess most would just do PLL on an OCLL-skip, but for a fair comparison with the COLL stats I need to assume that an OCLL-skip involves doing EP followed by CP. I've updated the stats to take account of this.

Cheers for spotting my error.

 

[oll+phase+sync]

I thought my idea is new :/ When I started cubing (petrus methode) I

- didn't like COLL recognition
- didn't know all of PLL
- while doing algorithm-free/intuitive F2L I was wondering if there is something usefull I could do.
- I wanted an easy 2 Look Last Layer


- So I started to use Phasing (meanwhile I must say it is even easier to like phasing the less F2L algorithems you know)
- So after phasing OCELL has just 14 cases
- For the solved cases: Sune must be replaced by Niklas , for H and Pi you need something new the rest ist standard OLL
- For "bar"-swap I also use Sune-Combos like "Sune U' Sune" for Pi or for T "BackwardSune Antisune" R'U2RUR'UR RU2R'U'RU'R' this made learning them a peace of cake (Many )

A perms are now my best friends

I also tried to avoid E Perms I started to Learn alternative and shorter Algorithems for many cases, but never finished because I switched to Roux meanwhile.


If you didn't succeed in phasing, there are often easy OCELL's you can establish phased state before PLL like DoubleSune / MirroredDoublesune for the H case but this requires 5 more PLL's to be learned N, T, F, Z
The benefit here is again that there is no recognition penalty for the OCELL case.


P.S.: Backward Sune means if you read it from right to left it's a Sune , another name would be mirror-anti-sune or anti-mirrorsune

 

[Rpotts]

about your PS - the way I name it (which isn't standard) that would be inverse anti sune.
for me sune is sune, and sune from the back right is anti sune (R' U' R U' R' U2 R)
Inverse is obvious, so inverse sune is R U2 R' U' R U' R', and therefore inverse anti sune is the case you're talking about, in my lingo.
just a thought.

 

[oll+phase+sync]

The problem with "anti" is that I'm not feeling cubers have a common sense what it should mean, do they?
Math would not define it either.
Lars Petrus for example has a third definition http://lar5.com/cube/fas6.html

But if anti means mirror it's still the question horizontal or vertical or diagonal.

So I hoped backward like dog = god but not g'o'd' is free of missunderstandings.

But you are right each of my anti would be clearer if I write invers.

 

[Lucas Garron]

Lars Petrus for example has a third definition http://lar5.com/cube/fas6.html

He does? It seems consistent with "inverse Sune," the accepted standard.

 

[oll+phase+sync]

He does? It seems consistent with "inverse Sune," the accepted standard.

citing Lars site:
"At left: Doing Sune™ backwards (AntiSune) twists corners the same way as Sune™, but moves the edges differently"

If you take a look at the cube applet, it get's 100% clear.

 

[Lucas Garron]

citing Lars site:
"At left: Doing Sune™ backwards (AntiSune) twists corners the same way as Sune™, but moves the edges differently"

If you take a look at the cube applet, it get's 100% clear.

Yeah, it does. It performs an "AntiSune" starting with F'.

 

[oll+phase+sync]

F' U2 F U F' U F or R' U2 R U R' U R is an AntiSune ? I'm confused. This means a Antisune solves the same OLL case as a Sune (ignoring AUF ) ?

 

[irontwig]

Yes those are anti-Sunes. Both (C)OLL cases can be solved with either a Sune or a anti-Sune.

 

[Shiv3r]

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

does this preserve corner permutation?

 

[Logiqx]

does this preserve corner permutation?

No. OCELL is followed by CPLL.

 

[Shiv3r]

If we got it to preserve corner permutation then we have a 1LLL from a 2-gen state.

 

[Logiqx]

If we got it to preserve corner permutation then we have a 1LLL from a 2-gen state.

That's just standard 2GLL.

 

[Shiv3r]

yeah, right.

 

[Shiv3r]

youre right.

 

[Shiv3r]

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


Interesting, I don't know how I missed that!
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..

I had an idea a while back of doing this but instead of solving the edges phasing them. Recognition is much easier(minimum number of sides to look at: 2 for phasing, and OCLL recog is trivial.), and the algorithm count is 14 new algs(and 7 OCLL that preserve phasing), and you also get 9 PLL algorithms, making it a good method for beginners.