# CLL+1: An Advanced LL Method (Complete and fully generated!)



## Athefre (Sep 26, 2020)

CLL+1

COLL+1

Around 10 years ago Thom Barlow (Kirjava) was talking about a new LL method. The idea is to solve CLL and a single edge in one algorithm. The second step would then just be an edge 3-cycle. For cross->F2l this means all that’s left is L3E. For ZZ or Petrus, this means all that’s left is a U-Perm. The problem was that a system hadn’t been fully developed to make it work. In July I thought of how to solve the problem and discussed it on the Roux Discord server. It turned out that TDM had similar ideas a few years ago. We discussed it for a while then I started development.

The way this LL method works is that there are four algs per CLL case when edges aren’t oriented (for when doing cross then F2L for example). The four algs are split into two sets. One set cycles the edges a certain way and the other set cycles them in a different way. Then, within each of these two-alg sets, one alg orients edges a certain way and the other alg orients the edges the opposite way. When all edges are oriented, such as in ZZ or Petrus, there are two algs per CLL case. One alg cycles edges a certain way and the other alg cycles them a different way. In total there are 166 cases for CLL+1 and 83 for COLL+1.

When edges aren’t oriented, you recognize the CLL case and the edge case for that CLL. You will memorize for each case which edge will be moved to the solved position. In the document linked at the top of this post, each case in the images has a number on it. Below those images will be two columns showing “Cycle 1” and “Cycle 2”. Locate your number below one of those columns. Each number shows which edge will be moved to the solved position when one of the algs above the number list is performed. To the left of each algorithm is an image that shows how the alg will flip all of the edges. During a solve, you note the orientation of the edge associated with the number and perform the algorithm that solves that case while also flipping that edge if necessary or keeping its orientation if it is already oriented. When all edges are oriented, you simply locate your number and perform the alg that solves the case. The all edges oriented version is also linked in this post as COLL+1.

This LL method makes for a great alternative. It works for when LL edges are either misoriented or oriented. It isn’t a huge number of algorithms compared to ZBLL and it provides the solver with a very short and easy second step compared to PLL. One major benefit is the high chance of skipping the second step. For Cross->F2L->CLL+1, there are only 10 L3E cases so skips will be pretty frequent. For ZZ, Petrus, and other methods which lead to an EO LL, there are only two L3E cases and those are the simple U-Perms. As for negatives, recognition for the first step takes longer than OLL because you are mostly recognizing the LL case. However, this is made up for by three additional advantages. The first is the short L3E cases. There are fewer long and or bad cases compared to PLL. The worst L3E cases are the 2-flip cases, of which there are two. The rest are either 7 or 9 moves each. The 2-flips can even be easily avoided by just using a different alg and more on that is described in the notes section below. The second advantage over PLL is the fact that L3E skips are more frequent than PLL skips. A final advantage over PLL is that, eventually, the L3E step takes zero recognition time. Because the solver is recognizing the edge case, they will eventually come to know exactly what L3E case will come after performing the CLL+1 alg. This means a perfect transition from CLL+1 to L3E.



Spoiler: Notes




Recognition is about the same as ZBLL. It actually becomes a little easier than that. This is because for each CLL+1 case, one alg solves 9/12 edge permutations and the other alg solves the other 3/12. So all the user is looking for is if the LL case is one of those 3/12 cases or not. If it isn’t, then they know to just use the other alg. This mostly applies to COLL+1. For CLL+1 that doesn’t always work because you need to check the edge that is going to be solved to see if you need to flip or preserve its orientation. Another way to recognize is to determine whether the edges are phased or unphased. This works for COLL+1 if you don’t care about knowing exactly which U-Perm will occur. However, for CLL+1 this recognition is difficult because you have to think during the recognition time about what kind of cycle your alg does to the edges to determine which edge will be moved to the solved position. You need to know which edge is being moved to the solved position so that you can choose the correct alg that either flips or preserves the orientation of that edge. I’m actually not completely sure about the phased/unphased recognition being effective for COLL+1 either. In the analysis that I’ve done, it seems that it doesn’t always work. For some cases, the phased edges alg would be required to be used on an unphased edges state. Also, thinking about it in this phased/unphased way doesn’t reveal what cases each alg is actually able to solve. An alg may be good for when edges are phased, but you wouldn’t know that you could instead use the other alg in the set. This other alg may be one that you greatly prefer.
There are patterns within the cases, so that means memorization will be easier than it first appears. Many cases contain the exact same list of numbers and the edges that are moved to the solved position are the same. I based the edge positions around the corners on the ZBLL sets on the wiki. If the edge positions were further made equivalent among all of the CLL cases, there would be even more patterns to make memorization easier.
In a set of algs, there is an overlap where both will solve many of the same cases from the list of 12. This means you can choose which alg you want to use. You can use the alg you like more and avoid the one you like less. Another important thing to note is that of course in 2/12 cases, one of the algs will correctly position all of the edges. For CLL+1 this means you can foresee the LL being completely solved and proceed that way. Or, once you are familiar with the cases, you can sometimes use the alg from the other set to force an L3E case that you prefer. Even though there are only a few L3E cases and each are short and good algs, this could provide an additional advantage. You’ll be able to see that using one alg will lead to a 2-flip, so you can use a different alg to avoid the 2-flip and have a more desirable L3E case.
You can learn another set of algs or use a different combination to further increase the chance of an L3E skip. You know how your alg cycles the edges and the L3E case it will lead to. For some cases you can use a new alg from a third set to cycle a different way – forcing an L3E skip or an L3E case you prefer.
If the corners are already solved, it is best to use ELL. For COLL+1, if the corners are oriented, it is best to use PLL. If using a method that gets to LL without intentionally orienting edges, but all LL edges happen to be oriented, the CLL+1 sets of algs may not contain two algs that preserve the orientation of all edges. So you have a choice of using CLL+1 and leading to L3E or learning another alg set (from COLL+1) to preserve the EO and lead to a U-Perm.
The diagonal O case only requires one type of cycle to solve an edge for each of the five possible edge permutations. This means another alg combination isn’t necessary. So for CLL+1, only two algs are needed and for COLL+1 only one alg is required. This works for two of the possible ways of cycling edges (either swapping UB+UL or UB+UR in my document and using my AUF alignment). If the diagonal swap alg cycles edges in ways different from those two, then an alg combination is required.
I have attached the Excel files that I created for this method. They contain all of the possible unions of cycles (the possible alg type combinations) that will solve a corner case and an edge. I am providing this to help users generate their own algs. So far I have only a few alg sets generated for each CLL case. The ultimate goal is to have an alg set generated for every cycle. There is also an alternate way of looking at how corners are swapped and edges cycled. An adjacent swap corner case can also be viewed as a cycle of three corners. This would accomplish the same result of solving the corners. Viewing it as a cycle of three corners means that you have to also view the edge cycle in an alternate way. With a corner adjacent swap, you can’t perform a 3-cycle of edges. But if you view that corner case as a 3-cycle of corners, then you can perform a 3-cycle of edges. This alternate way of thinking about cases didn’t prove to be of any use for CLL+1. I’m only providing this explanation in case someone considers this alternate view and questions the benefits. There could be an advantage that I didn’t see, so if anyone wants the analysis of this alternate view I did generate that also and can provide it.
You may eventually ask yourself if it’s possible to add a third alg into the union for COLL+1 and solve all edges using just 120 algs. I did update my predictor to test this. It turns out that it is possible…if the edges are in an illegal state. Meaning if you take out two edges and put them back in the wrong positions. So maybe there is a method that could take advantage of this property. Such as having two edges at DF+DB swapped; causing the LL edges to be in that illegal state.
Additional Tricks: Can use transformation tricks to further reduce the number of cases, avoid cases you don’t like, or force an L3E skip. R or L moves can position a pre-made pair and change the LL to a different case. M moves can move edges into a more advantageous position. This hasn’t been explored yet, so the beneficial uses need to be documented.






Spoiler: History



Around 2011 is when this LL idea was first being talked about. It may have been an idea from Thom Barlow (Kirjava) or he had seen the idea somewhere else. He was sometimes talking about an LL method he was calling CLL+1 and making example solves. The problem was that he didn’t have a system for how to make it work. So he was asking here on the forum if anyone had ideas. I suggested a couple of systems that would work, but they weren’t perfect. The idea eventually kind of went away. A few years later, some users discussed the idea of using two COLLs per case for ZZ and taking advantage of the phased/unphased edges state to force a U-Perm. That was essentially COLL+1. Then TDM had the idea of being able to extend it to an LL with misoriented edges by having one algorithm with a certain edge orientation and another algorithm with the reverted orientation. This made it become the original CLL+1 idea.

In July of this year, unaware of those posts, I had the same ideas myself. Except, instead of the phased/unphased edges idea that others were thinking, I discovered a new kind of system where two or more algorithms can be combined like a Venn diagram. For CLL+1 this means that one algorithm does one type of edge cycle and the other algorithm does a different edge cycle. These two cycles overlap to solve an edge in all cases. The system is called the Cycle Union System and you can learn more about it here. It has many applications beyond CLL+1.



Development File: CLL+1 Unions
Development File: CLL+1 System

*Alg sources:*

CubeExplorer – Most algs were found here.
The most popular Roux 2H alg sheet: https://docs.google.com/spreadsheet...1yzTjnqSMS3D3dZcsCIOiJqcI/edit#gid=1701452193
Algdb.net
SpeedSolving Wiki
TDM – The four algs for the adjacent swap O case were provided by TDM. Also, TDM has found good CMLL algs over the years and they are within the CMLL document in the link above. Some of them proved to be helpful in developing CLL+1.
This was a huge project that took close to three months, so it is likely that there are a few mistakes. Possibly even big mistakes. If you notice anything, please let me know.


----------



## TheSlykrCubr (Sep 26, 2020)

damn dis big. how many algs altogether?


----------



## PapaSmurf (Sep 26, 2020)

Chish and Fips is completed (sounds way better than CLL+1). But this is really cool (and quite possibly better than a bad OLL->PLL).


TheSlykrCubr said:


> damn dis big. how many algs altogether?


It says if you read the first 2 paragraphs.

Having a 1LLL with this is pretty feasible. All it takes is knowing where 2 more edges will end up, leading to a pausless LL. Do you have the average movecount of this too? L3E is ~8, so if Chish is ~12 you have a LL that is extremely efficient.


----------



## Athefre (Sep 26, 2020)

PapaSmurf said:


> Chish and Fips is completed (sounds way better than CLL+1). But this is really cool (and quite possibly better than a bad OLL->PLL).
> 
> It says if you read the first 2 paragraphs.
> 
> Having a 1LLL with this is pretty feasible. All it takes is knowing where 2 more edges will end up, leading to a pausless LL. Do you have the average movecount of this too? L3E is ~8, so if Chish is ~12 you have a LL that is extremely efficient.



Very close actually. The average movecount is 13.1. And this is considering the fact that I spent a lot of time choosing longer fast algs instead of prioritizing movecount. This is essentially a 1LLL. Once the user has used the algs for a while they will know what is going to happen to the other three edges after applying a certain alg to a specific case.

Also, I added the number of cases after seeing TheSlykrCubr's post. I just hadn't replied yet.


----------



## Username: Username: (Sep 26, 2020)

Finally, you have completed CLL + 1, this is big, very nice Athefre.


----------



## PapaSmurf (Sep 26, 2020)

I wonder how difficult CLL+2 would be (in a Zipper context). To simplify everything, you solve the edge that is in FR and the edge that is where FR belongs.

FR solved: 166 cases
FR flipped: 166 cases
FR to UL: 252 cases
FR to LU: 252 cases
FR to UF: 252 cases
FR to FU: 252 cases
FR to UB: 240 cases
FR to BU: 240 cases
FR to UR: 240 cases
FR to RU: 240 cases. 

This is a lot (2300). This does assume a few things though and alg count could very possibly be cut down by a fair few (perhaps half). I could've also counted incorrectly. It could be pretty good, but regular Zipper LSLL would work probably equally as well.


----------



## Athefre (Sep 26, 2020)

PapaSmurf said:


> I wonder how difficult CLL+2 would be (in a Zipper context). To simplify everything, you solve the edge that is in FR and the edge that is where FR belongs.
> 
> FR solved: 166 cases
> FR flipped: 166 cases
> ...



I think it would be much fewer cases than even half of this. Keep watch on the forums because I'll be posting something that solves this problem and many others. I'll post it in a day or two once CLL+1 has had time to be seen.


----------



## PapaSmurf (Sep 26, 2020)

Oooooh, exciting!


----------



## tx789 (Sep 27, 2020)

I once asked in the old irc about this in 2011 apparently someone had figured out only ~96 algs we're needed.


----------



## Athefre (Sep 27, 2020)

tx789 said:


> I once asked in the old irc about this in 2011 apparently someone had figured out only ~96 algs we're needed.



Do you remember what kind of system was used? Was this for CLL+1 or COLL+1? It may have been one that required an additional trick. One I suggested back then was to ensure that a pair is pre-made on the LL. Another I suggested was to do M2 to place the edge you want to solve at DB and have the algs cycle DB->UR->UL. Both of those would have around that 96 algs, but they require extra effort and moves.

Using my system that solves this the right way it is possible that the number of algs can be reduced. This is because an orientation trick was used instead of being completely incorporated into the algs. I actually have more written about this in a topic that I'll be posting soon about the system.


----------



## efattah (Sep 27, 2020)

CLL+1 actually dates back to Waterman in the 1980's. In basic Waterman you solve CLL, but near the end of Waterman's cubing career he began to solve 1 top layer edge at the same time as CLL. In his case, what he did was modify CLL algorithms to switch R to r and L to l and in some cases this doesn't change the movecount but changes the effect on the edges, in other cases you needed to inject an M or M' to compensate for the R->r or L->l. The end result was several variants of each CLL algorithm with different effects on the edges, allowing a single edge to be solved with essentially no extra moves vs. standard CLL.


----------



## Athefre (Sep 27, 2020)

efattah said:


> CLL+1 actually dates back to Waterman in the 1980's. In basic Waterman you solve CLL, but near the end of Waterman's cubing career he began to solve 1 top layer edge at the same time as CLL. In his case, what he did was modify CLL algorithms to switch R to r and L to l and in some cases this doesn't change the movecount but changes the effect on the edges, in other cases you needed to inject an M or M' to compensate for the R->r or L->l. The end result was several variants of each CLL algorithm with different effects on the edges, allowing a single edge to be solved with essentially no extra moves vs. standard CLL.



Not sure why I didn't know this. Thanks for the information. I would classify the Waterman CLL+1 as something kind of different from the LL only CLL+1. This is because there are so many more edges involved in the Waterman version and because it would be a more intuitive approach to developing the algs.


----------



## ZB2op (Sep 28, 2020)

From what i've just read this is almost certainly not worth it in terms of time but sounds like something fun to try out


----------



## PapaSmurf (Sep 29, 2020)

Why not? You have an alg that is equivalent to OLL then you have an alg that is faster than your average PLL. I get that the recog might be a bit slower, but not by enough to outweigh.


----------



## RadicalMacaroni (Oct 2, 2020)

PapaSmurf said:


> Why not? You have an alg that is equivalent to OLL then you have an alg that is faster than your average PLL. I get that the recog might be a bit slower, but not by enough to outweigh.


but it is slower enough to outweight because oll/pll recog are extremely fast and the algs are also extremely fast


----------



## PapaSmurf (Oct 2, 2020)

I guess someone will have to learn it and get as fast as they can with both CLL+1/L3E and OLL/PLL to see.


----------



## Athefre (Oct 2, 2020)

OLL+PLL has been around for ~40 years and has had thousands of people analyze and develop the best algs, recognition, and strategies. CLL+1 has been around for 6 days and has had one person put development effort into it. I think I did a great job finding good algs, but with community involvement even better algs will be found.

*Step 1:*
OLL vs CLL+1:
+ Recognition: OLL takes less time to recognize.
+ Algs: OLL algs are a little shorter and faster.
+ Skip: Higher chance of a skip with OLL, but even then it is only 1/216. So not a very important measurement.

*Step 2:*
PLL vs L3E:
+ Recognition: L3E has 0 recognition time. There is a pauseless transition from CLL+1 to L3E after someone uses the method for long enough to learn the cases well. PLL recognition is usually fast, but even at the top level there are sometimes unwanted pauses.
+ Algs: L3E averages 9 moves and has better algs. Sometimes the last move of CLL+1 can even be canceled into the first move of L3E because the solver always knows the case that is coming. PLL is fast, but some algs are close to 20 moves.
+ Skip: 1/12 skip chance for L3E vs 1/72 for PLL. Huge difference. Imagine this at a competition. There are several rounds at a competition. You are probably going to get a second step skip with CLL+1 in at least one solve. Not so guaranteed for PLL.

I have provided all of the possible combinations in the development files in the main post. This will allow users to find even better algs than what one person was able to do. There are so many other possible algs that can be used. There are also recognition tricks that haven't been detailed.


----------



## xyzzy (Oct 4, 2020)

Let me preface this by clarifying that I'm not saying that this is a bad method or anything (it looks promising, actually); I'm just nitpicking bad statistics.



Athefre said:


> + Skip: 1/12 skip chance for L3E vs 1/72 for PLL. Huge difference. Imagine this at a competition. There are several rounds at a competition. You are probably going to get a second step skip with CLL+1 in at least one solve. Not so guaranteed for PLL.


You cannot assume that the L3E cases will be equally likely! The true probability of an L3E skip is _at most_ 1/24 (plus epsilon), or only around 1/48 for most CLL cases with the basic method (use the "Cycle 1" alg when it'll lead to L3E, the "Cycle 2" alg otherwise).

(The "plus epsilon" is to account for symmetric OLLCP cases, where the probability of an L3E skip can indeed be as high as 1/12 or 1/6. I'll be ignoring this henceforth, since symmetric OLLCP cases are rare.)

You do get a probability of 1/6 L3E skip with COLL+1, but even then, the probability distribution of the U perms (considered together with the angle) is not uniform. Perhaps Ua will be more common, perhaps Ub will be more common, perhaps having a left bar will be more common (RUS U perms!), etc.



Spoiler: why



Consider a different CLL+1 system, where after recognising the CLL case and AUFing, we choose one of eight algs that will solve whatever edge is currently at the UF position. For example, for the Sune CLL case (R U R' U R U2 R'), we might choose these eight algs:

(U') R' U2 R U R' U R / r U r' U R U' R' r U' r'
R U R' U R U2 R' / F U R' F R F' R U' R' F'
R U R' U R2 U R U R2 U' R' U' R2 / F' U R U R2 u' R2 u R U2 F
(U') R' U' R U R U R' U' R' U R U R U' R' / r U R' U R U2 r'

(I didn't try particularly hard to optimise the alg choices.)

In _this_ CLL+1 system, the permutation and the orientation of the three edges we don't look at are completely undetermined, and so we really have a 1/3 chance of EP skip and 1/4 chance of EO skip, for a total 1/12 chance of L3E skip. 

In the CLL+1 system proposed in this thread, we're _not_ solving a specific edge, which means that we can no longer safely assume that the remaining three edges are completely undetermined. Indeed, there's an even simpler way of seeing that the L3E skip rate can't possibly be as high as 1/12: an L3E skip is equivalent to doing 1LLL, but if you're learning only 4 algs out of each CLL subset of (4!/2) × 2^3 = 96 algs, how can you be doing 1LLL more than 4/96 = 1/24 of the time?



---
(throwing in a reply to the bottom post by Athefre because it's not really on-topic)



Athefre said:


> I received the numbers from a couple of people on Discord. They both gave the same number, so I trusted the calculation.


Probability is weird like that: one could come up with many different probabilities for a well-defined event, all with seemingly reasonable and intuitive justifications, and yet only one of the answers can be correct. Outside of cubing, the Monty Hall problem is the classic example (yes, you should switch); within cubing, case probabilities in steps like LSLL is the natural example (the probability of an LS skip is less than 1/150 under reasonable assumptions).

Probability is hard, but getting it right also seems to be pretty important when trying to develop methods, especially methods that involve new algs that you haven't gotten into muscle memory. In lieu of actual empirical data of how well a new method performs, having some objective metric like average move count to serve as a proxy would be nice. And even then, empirical data is hard to come by when we're looking at marginal differences between methods (e.g. methods that differ by only a quarter of a move on average); the smaller the difference, the more work you have to do to be certain of it. (And it's not linear! You have to do _quadratically_ more work!)

To be fair, the mistake made here (that L3E skip is 1/12) doesn't substantially affect the calculus, and it's why I just stated up front that this was statistical nitpicking.


----------



## Athefre (Oct 4, 2020)

xyzzy said:


> Let me preface this by clarifying that I'm not saying that this is a bad method or anything (it looks promising, actually); I'm just nitpicking bad statistics.
> 
> 
> You cannot assume that the L3E cases will be equally likely! The true probability of an L3E skip is _at most_ 1/24 (plus epsilon), or only around 1/48 for most CLL cases with the basic method (use the "Cycle 1" alg when it'll lead to L3E, the "Cycle 2" alg otherwise).
> ...



Thanks for this. In this community, I'm a full-time method developer and I think I've discovered and developed some great things. However, a huge weakness of mine has always been group theory. It really is something that I should know. It has slowed down development time for some of my projects. It has also kept me from being able to prove advantages. I think CLL+1 is the only time that I've ever provided numbers like this. I received the numbers from a couple of people on Discord. They both gave the same number, so I trusted the calculation. But I guess maybe I should have just left it out of the posts.

I really appreciate the amount of thought and effort that you put into your reply. Thank you.


----------



## trangium (Nov 6, 2020)

How would one go about recognizing CLL+1 after recognizing the CLL case? Like what exactly would I look for on the scramble B2 R F2 R B2 L' B2 R D2 R B' L B2 R F2 R' B? Would the recognition be significantly harder if CLL+1 was done entirely with cycle unions and without the orientation trick? Depending on how easy the recognition is, I might start learning this set.

Also a note on anyone who wants to contribute to the algs: cycle unions are not needed to generate algs if the orientation trick is used. To generate the algs for a specific CLL case, find two algs for that CLL case where applying the inverse of one algorithm then solving the corners with the other algorithm leads to an ELL case with exactly one solved or flipped edge, then find the two algs that are a 4-flip away from the original two. For example, for the Sune pure twist case, I found R U R' U R U2 R' and r' R2 U R' U r U2 r' U M'. Applying R U2 R' U' R U' R' then r' R2 U R' U r U2 r' U M' leads to an ELL case with exactly one flipped edge, so we know this pair works. Then I found F R U R' U' F' R U R' F' U2 F R U' R' and R' U2 R2 U R2 U R U' R U' R' which are a 4-flip away from the first two cases.


----------



## Athefre (Nov 6, 2020)

trangium said:


> How would one go about recognizing CLL+1 after recognizing the CLL case? Like what exactly would I look for on the scramble B2 R F2 R B2 L' B2 R D2 R B' L B2 R F2 R' B? Would the recognition be significantly harder if CLL+1 was done entirely with cycle unions and without the orientation trick? Depending on how easy the recognition is, I might start learning this set.



The idea is to recognize as ZBLL. There are a few ways of doing that. I'm not yet sure which is best for CLL+1. During development I was mentally flipping edges, but maybe there's a better way. I talked a bit about recognition before, but it's definitely something that could be developed. I'm also curious about how recognition will work once the orientation trick is removed. It may be that it is fewer cases but more difficult recognition. Or recognition may turn out to be pretty much the same. I'll have to finish it and examine the unions to really know.

For the scramble: After identifying the corner case, I would see that RU matches RFU and FU matches URF. For this case I would know that the edge at UR will be solved. That edge is oriented, so the alg is U R U2 R2 U' R U' R' U2 F R F'. This is how I was recognizing during development tests. I'm not an experienced ZBLL user, so I'm sure there are better ways.



> Also a note on anyone who wants to contribute to the algs: cycle unions are not needed to generate algs if the orientation trick is used. To generate the algs for a specific CLL case, find two algs for that CLL case where applying the inverse of one algorithm then solving the corners with the other algorithm leads to an ELL case with exactly one solved or flipped edge, then find the two algs that are a 4-flip away from the original two. For example, for the Sune pure twist case, I found R U R' U R U2 R' and r' R2 U R' U r U2 r' U M'. Applying R U2 R' U' R U' R' then r' R2 U R' U r U2 r' U M' leads to an ELL case with exactly one flipped edge, so we know this pair works. Then I found F R U R' U' F' R U R' F' U2 F R U' R' and R' U2 R2 U R2 U R U' R U' R' which are a 4-flip away from the first two cases.



This is an interesting way of finding the algs. Pretty cool. In the conversations I had with TDM, he also had his own way of finding algs. His rule was that the second alg in the pair needs to be a 3-cycle difference from the first alg in the pair. I have already provided all of the possible combinations in the development files of the original post. No one has to use cycle unions anymore for CLL+1. All that is needed is to check the document, set up the corner case in CubeExplorer, and set it so that it will cycle the edges the desired way. All of the cases are in the document. So there's no need to find algs. They only need to be generated.

Well, I say that cycle unions doesn't need to be used anymore for CLL+1. However, I would like to get rid of the orientation trick and see how well it works. I have the first half of the cycle simulator built in Excel. It's just a matter of finding time to get it finished. 2,300 cycle simulations per CLL case.


----------



## abunickabhi (Nov 6, 2020)

Nice idea. I got it works practically. How do you simulate all the cycles. ZBLL conventional recognition isnt that good (just seeing block). I think recognizing COLL and the corresponding EPLL that is embedded in that LL is a better way of recognizing.


----------



## Athefre (Nov 7, 2020)

abunickabhi said:


> Nice idea. I got it works practically. How do you simulate all the cycles. ZBLL conventional recognition isnt that good (just seeing block). I think recognizing COLL and the corresponding EPLL that is embedded in that LL is a better way of recognizing.



I set up a cross shape of five cells. The center is labeled with the type of cycle (U-Perm, H-Perm, Infinity Cycle, etc.). The cell to the left, top, right, and bottom contain a letter code for the color of the edge on the cube. For ZBLL, I have a set of 12 of these 5-cell groups. These are all of the possible ZBLL edge positions. To the right of this group of 12 I have an identical group. Except that inside of the color code cells is instead a formula that grabs the color from a different location of the corresponding 5-cell group. It pulls from a certain location depending on the labeled cycle in the center of the 5-cell groups. This is the cycle simulator. There are 24 possible ways of cycling the edges, so I have 24 of these 12 sets of 5-cell groups. Each with a cycle simulator to the right. For the full cycle union application to remove the orientation trick, there will be 96 5-cell groups per 24 ways of cycling the edges. I provided my cycle simulator in the main post if you're interested in seeing more about how it works.

There are several ways of recognizing ZBLL, which means that there are several ways of recognizing CLL+1. I wonder which would be the best. Blocks, mentally twisting pieces to form PLL, and CLL then EP are three of the ZBLL options. Maybe one of the ZBLL methods, something unique, or a combination would be the way to go.


----------



## trangium (Nov 14, 2020)

Another thing to note is that ELLs with no edges solved are only 3.623 STM worse than ELLs with one or more edges solved on average, using my ELLs, so any CLL+1 cases that are more than 3 moves slower than the standard CLL won't be worth it. 
For reference, here is my list of ELLs: https://tinyurl.com/yyg8s9fb


----------



## Athefre (Nov 15, 2020)

That's an interesting point. It could be that for some cases, users will prefer to do CLL then ELL or OLL then PLL. Similar to how some people don't recommend S/AS for COLL and instead suggest OCLL+PLL for those cases. At least for move-count it makes sense. Overall recognition would take a hit though. Because CLL+1 guarantees a pauseless L3E, that is something that would be lost. So maybe the determination to be made for those cases is what is faster. The move difference for CLL+1 or recognition time for a different method.


----------



## Athefre (Aug 2, 2022)

Some thoughts on Union CLL+1 versus All Cases (300+ algs) CLL+1.

*Recognition (after recognizing the CLL case):

Union CLL+1* - First find the edge orientation, which is 3 stickers. Then recognition is process of elimination style where cases will be either in this group or the other one. The user checks either 1 or 2 stickers on the edges currently at UF and UR to find the permutation. No need to know anything about the edges currently at UL and UB. This is 4-5 stickers total and the user is only checking whether the current case is one of 3 specific cases. If it is, use the single alg that solves an edge in all three of those cases. If it isn't one of those 3 cases, use the other alg that solves an edge in all 9 of the remaining cases. There's no reason to look any deeper into the case and recall one of several algs. There is also no need to check or worry about hidden stickers on L or B. All recognition can be done on U, F, and R if you know the edge cases.

*All Cases CLL+1* - The user would have a set edge location to solve every time for every case. Say for Sune with the oriented corner placed at UFL you want to always solve the edge that goes to UF. Recognition would be: Check the FUL sticker to know what edge you are looking for then locate the edge. This edge can be in any of the four positions and possibly the identifying sticker hidden on L or B. With the edge having the possibility of being in several positions and two orientations, does this mean that many more stickers are required to be checked versus Union CLL+1? Or, how do we quantify a kind of passive scan of stickers which users would probably do? Also, how would the CLL angles be handled? For example, when the Sune case is a U or U2 away and you can't see the corner sticker to know what edge you need to look for. Maybe by adding in additional knowledge to your CLL recognition patterns? The corner sticker and or the edge you are looking for can be hidden in a large percentage of solves.

*Algorithm quality:*

I think the algorithm quality of Union CLL+1 is better overall than the 300 algorithm version of CLL+1. This is because the 300 alg version will include all of the possible bad cases. These bad cases can often be avoided in Union CLL+1. This is accomplished by choosing the unions which contain the best algorithms. Most bad cases can be avoided and most of the best cases will be included. There's also an addition by trangium which takes advantage of the orientation trick of the union version of CLL+1. A third algorithm can be incorporated into the union to allow for even better algorithms.

I think if the algorithms for the union version of CLL+1 were regenerated by a few people we would see some great results. I didn't incorporate S or f moves when I made the document. Additional help from the community and additional movesets will make this even better.


----------



## OreKehStrah (Aug 2, 2022)

Athefre said:


> Some thoughts on Union CLL+1 versus All Cases (300+ algs) CLL+1.
> 
> *Recognition (after recognizing the CLL case):
> 
> ...


Something I was playing around with for the full CLL+1 thing is not quite what you mentioned. Basically I would recog the OLL then CP and then use the UFR corner as the reference, then look at the UF edge and determine where it needed to move relative to the UFR reference.


----------



## Athefre (Aug 2, 2022)

OreKehStrah said:


> Something I was playing around with for the full CLL+1 thing is not quite what you mentioned. Basically I would recog the OLL then CP and then use the UFR corner as the reference, then look at the UF edge and determine where it needed to move relative to the UFR reference.


That definitely helps with recognition. No need to worry about hidden stickers. I guess OLL first recognition would work for the union version as well.

Using that style, recognition comes down to:

Union: OLL > CP > UF edge sticker and or UR edge sticker to determine which of the two algs to use.

Full: OLL > CP > FU edge sticker and one of the UFR corner stickers.

Looks pretty equal. Possibly just a bit more calculation required for full CLL+1 for were the edge needs to go. Maybe that can helped with a good memory during CP recognition.


----------



## OreKehStrah (Aug 2, 2022)

Athefre said:


> That definitely helps with recognition. No need to worry about hidden stickers. I guess OLL first recognition would work for the union version as well.
> 
> Using that style, recognition comes down to:
> 
> ...


Yeah I think using unions that use either the UF or UR edge would be nicer for recognition.


----------

