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



## Cride5 (Oct 9, 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: *O*rient *C*orners [permute] *E*dges *L*ast *L*ayer. It could also be called OCEPLL, but that would be a bit of a mouthfull 

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*


----------



## miniGOINGS (Oct 9, 2009)

Haha, I've been waiting for this!


----------



## blah (Oct 9, 2009)

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.


----------



## Cride5 (Oct 9, 2009)

blah said:


> A : E : H : CPLL skip = U : Z : H : EPLL skip = 8 : 2 : 1 : 1





Cride5 said:


> *CPLL*:
> Case | Moves | Prob Occurance
> -------+-------+---------------
> A(a) | 9 | 4/12
> ...



What are you getting at??



blah said:


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


----------



## StachuK1992 (Oct 9, 2009)

Cride. Use courier new to do the chart, so it actually looks nice.
Also, why this as opposed to COLL?


----------



## LarsN (Oct 9, 2009)

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


----------



## ErikJ (Oct 9, 2009)

I don't see any advantages of this.


----------



## fanwuq (Oct 9, 2009)

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.


----------



## Cride5 (Oct 9, 2009)

LarsN said:


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



fanwuq said:


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


----------



## fanwuq (Oct 9, 2009)

Cride5 said:


> 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 (Oct 9, 2009)

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


----------



## Weston (Oct 9, 2009)

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


----------



## Lofty (Oct 9, 2009)

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 (Oct 9, 2009)

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.


----------



## eastamazonantidote (Oct 9, 2009)

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 (Oct 9, 2009)

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 (Oct 9, 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

~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 (Oct 10, 2009)

eastamazonantidote said:


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


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.


----------



## 4Chan (Oct 10, 2009)

Cride5 said:


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



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)


----------



## eastamazonantidote (Oct 13, 2009)

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.


----------



## Spitfire97 (Nov 14, 2009)

where do you recognize these cases from?


----------



## Cride5 (Aug 8, 2010)

*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 (Aug 8, 2010)

Optimal COLL+EPLL in STM is 16.95, though.


----------



## qqwref (Aug 9, 2010)

Cride5 said:


> H | 11.33 | 2/27
> Pi | 10.5 | 4/27
> Hlight| 10 | 4/27
> T | 9.67 | 4/27
> ...


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 (Aug 10, 2010)

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 (Oct 27, 2010)

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 (Oct 28, 2010)

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 (Nov 18, 2010)

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 (Nov 18, 2010)

oll+phase+sync said:


> 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 (Nov 18, 2010)

Lucas Garron said:


> 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 (Nov 18, 2010)

oll+phase+sync said:


> 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 (Nov 19, 2010)

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 (Nov 19, 2010)

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


----------



## Shiv3r (May 3, 2016)

Cride5 said:


> 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: *O*rient *C*orners [permute] *E*dges *L*ast *L*ayer. It could also be called OCEPLL, but that would be a bit of a mouthfull
> 
> 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.
> 
> ...


does this preserve corner permutation?


----------



## Logiqx (May 3, 2016)

Shiv3r said:


> does this preserve corner permutation?



No. OCELL is followed by CPLL.


----------



## Shiv3r (May 3, 2016)

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


----------



## Logiqx (May 3, 2016)

Shiv3r said:


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



That's just standard 2GLL.


----------



## Shiv3r (May 3, 2016)

yeah, right.


----------



## Shiv3r (May 3, 2016)

youre right.


----------



## Shiv3r (Jul 11, 2016)

Cride5 said:


> Thanks
> 
> With regards to move count:
> COLL: 9.78 (source: http://www.ai.univ-paris8.fr/~bh/cube/)
> ...


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.


----------



## Daniel Lin (Jul 11, 2016)

Shiv3r said:


> Recognition is much easier(minimum number of sides to look at: 2 for phasing, and OCLL recog is trivial.),


all OCELLs can already be recognized from 2 sides (after you recognize OCLL)


----------



## AlphaSheep (Jul 12, 2016)

Shiv3r said:


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


While you can theoretically recognise the cases from only 2 sides, I'd like you to explain how you would do it without also looking at corner permutation, in a way that a beginner would understand. The easy recognition I would have picked would have involved looking at three sides - look at an edge in RU, for example, and then check FU and LU for it's opposite.

To me it looks like you're describing a method that involves learning 14 new relatively difficult to recognise OCELL algs to avoid having to learn 12 easy to recognise PLLs.


----------



## Shiv3r (Jul 12, 2016)

no, you AUF the OCLL alg, then check two adjacent sides. if the edges match, you have one phasing case. if they don't you have another phasing case.


----------



## xyzzy (Jul 12, 2016)

Shiv3r said:


> if the edges match, you have one phasing case. if they don't you have another phasing case.



If the edges don't match, you have two phasing cases which you cannot distinguish just from the two visible edges, because you don't know what the edges on the two sides you can't see are (unless you recognise the corner permutation, at which point why not just use COLL).

You could sorta salvage the idea by antiphasing instead (which can be done by looking at two edges in the way you suggest), so you have the 12 non-phased PLL cases along with 14 CO+antiphasing algs.


----------



## Shiv3r (Jul 12, 2016)

if the edges dont match then you know the other adjacent edge will be the opposite color of the middle piece. if it isnt, then they are already phased, which by taking a quick glance at the cube you can tell before you look at the sides.
I think recog would actually be easier than OCELL, i think.


----------



## AlphaSheep (Jul 13, 2016)

Shiv3r said:


> if the edges dont match then you know the other adjacent edge will be the opposite color of the middle piece. if it isnt, then they are already phased, which by taking a quick glance at the cube you can tell before you look at the sides.
> I think recog would actually be easier than OCELL, i think.



I disagree.

Example: OCLL is a H case with yellow on top and with the yellow corner stickers pointing right and left. FU edge sticker is red, RU edge sticker is blue.
Without looking at a third side, can you tell if this a case which needs phasing?


----------



## Shiv3r (Jul 13, 2016)

AlphaSheep said:


> I disagree.
> 
> Example: OCLL is a H case with yellow on top and with the yellow corner stickers pointing right and left. FU edge sticker is red, RU edge sticker is blue.
> Without looking at a third side, can you tell if this a case which needs phasing?


when recognizig the H case I would recognize all the edges were phased or not(pretty easy to tell when looking at an OCLL case). if they werent, you have one case, if they were, Id probably do an F(triple sexy)F' as that one keeps phasing.


----------



## Ahmed Saad Sabit (Dec 26, 2016)

Thats better than COLL. Many thanks


----------



## Daniel Lin (Dec 26, 2016)

Ahmed Saad Sabit said:


> Thats better than COLL.


nope, it's worse than COLL

(don't learn it unless you're doing ZBLL)


----------



## Shiv3r (Dec 26, 2016)

Daniel Lin said:


> nope, it's worse than COLL
> 
> (don't learn it unless you're doing ZBLL)


amens.


----------

