Cycle Union System: A New Approach to Method Development

Athefre

Member
Introducing the Cycle Union System

There was a problem in method development which hadn’t yet been solved. Think about the LL methods and other algorithm-based steps that are commonly used. They usually do one kind of step at a time. COLL+EPLL solves the corners then the edges. OLL+PLL orients all pieces then permutes all pieces. Rarely are there methods which directly solve more than one type of piece. This is because direct solving a mix of piece types seemingly results in a very large number of cases if we rely upon the traditional way of case calculation. To use a simple example, maybe you want to use an algorithm to solve the four LL corners and one LL edge. The typical approach would be to first find the number of CLL cases, which is 42. Then you choose to solve the UF edge and say that it has four positions (UF, UL, UB, or UR) and two orientations. That’s 8 possibilities for the UF edge. Multiplying the 42 corner cases by the 8 edge cases means 336 total cases. But why can’t we take advantage of the situation and solve any of the four edges? That would be fewer cases and would allow for the best algorithms. But how do you do that? This is what the cycle union system solves. A set of algorithms is found that overlaps in solving a group of cases. It is called a union because the system works like a Venn diagram. Using unions, the number of cases is drastically reduced – or, really, the true number of cases is revealed. This is accomplished without adding any extra moves or thinking time. Below are the steps for how to implement this system.

Step 1 – Primary Piece Cases: Find the full set of cases for the primary pieces that you want to solve. In CLL+1 for example, the primary pieces will be the four corners (42 cases). In Fish and Chips, the primary pieces would be the four LL edges.

Step 2 – Secondary Piece Cases: Find all of the possible cases for the secondary pieces. Here you determine all of the possible ways that the pieces can be configured around the primary pieces. In CLL+1, this would be all of the possible edge positions and orientations for each CLL case. There are typically 12 edge permutations and 8 edge orientations for each CLL case.

Step 3 – Secondary Piece Possible Cycles: Find all of the possible ways that you can cycle the non-primary pieces while solving the primary pieces. Using CLL+1 as an example, after recognizing the corner case, there are 24 possible ways to cycle, or permute, the edges. The UL+UR+UF edges can be cycled clockwise, UF+UB can be swapped, and so on.

Step 4 – Unions: Take every possible case from steps 1 and 2 and perform or simulate all of the possible cycles of the secondary pieces that were found in step 3. Build a table or list of what effect this has for each case. Among all of these simulated cycles, find each instance where a secondary piece is solved in the way that you want it to be solved. Using CLL+1 as an example, for each of the 12 possible edge permutations you would simulate all of the 24 possible ways of cycling the edges. Some of these cycles will place an edge into its correct slot within the corner case. Within the set of 12 possible edge permutations, there is never a single cycle that solves an edge for all 12 cases (except for the solved corner case and the oriented diagonal swap corner case). A cycle may solve an edge in cases 1, 2, 4, 5, 6, 7, 8, 9, and 10, but not in cases 3, 11, and 12. So look at the other 23 cycles that you simulated. One or more of those cycles likely solves all of those remaining three cases. It turns out that for CLL+1, it only takes a union of two cycles to solve an edge for each CLL case. This is versus the standard approach which might would be to recognize the corner case, choose a slot such as UF to solve an edge, then locate the UF edge. If all edges are oriented, the number of cases for this approach would be 4xCLL, or ~168 cases. With unions, the number of cases is only 2xCLL, or ~84 cases. The goal is to find the overlap among the cycle simulations where two or more cycles solve an entire set of secondary pieces within one of the primary piece cases. The image below, a Venn diagram, shows how this overlap works. It is a union of two cycles that solves an edge for CLL+1. Both algorithms solve an edge in cases 2, 3, 8, 10, 11, and 12. But only the algorithm on the left solves an edge in cases 1, 4, and 7 and only the algorithm on the right solves an edge in cases 5, 6, and 9. For some methods, a union of three or more cycles may be what solves a set of cases.

To determine all of the possible unions, what you want to do is create a table. Have the rows (or columns) contain a list of all of the possible cases for the pieces that you are trying to solve. This could be just the secondary pieces, such as the edges in CLL+1. Or it could contain both the primary and secondary pieces combined for the more complex methods. For higher order cubes, other puzzles, or other situations, even more piece types may be combined. Then have the column headers (or rows) contain a list of all of the possible ways in which those pieces can be affected. Such as doing a three-cycle, keeping a set of pieces in place, a pure orientation of two pieces, and so on. Include every possibility so that accurate results will be achieved. Once this table is created, you can code a simulation of what each effect, or cycle, does to every case. This is checking whether the cycle is placing the pieces into the position that you want them to be. For most methods, it is simply determining whether the pieces are solved by the cycle. Now that the table is completely filled in with what cycle solves which case, all that’s left is to go through and find the set of two, or more, cycles that solve the pieces for every case. If you placed your cycles in the column headers, you are finding where one or more columns can be overlapped and every cell is filled in. Below is an example. In the image, the Cycle 4 column contains four missing cases where it doesn’t solve what was intended. However, the Cycle 2 column contains all four of the missing positions. Cycle 2 solves all four of the cases that Cycle 4 can’t. So if those two cycles are combined, every case can be solved.
Step 5 - Application: You have now found the unions that solve the intended set of pieces. All that is left is to generate the algorithms. These algorithms solve the primary piece case while simultaneously performing the cycles selected in step 4. Label each of the cases with which algorithm should be used. You will memorize which algorithm within the union is associated with each case. Now, during a solve, you recognize the case then execute the correct algorithm. You are only performing a single algorithm from the union; not all of the algorithms that form the union.

To describe this system in its most basic form, there are two main parts. The first part is the principle of algorithms having the ability to be overlapped to solve multiple cases, solve a single case, or to set up to any desired position. This is what I discovered first and is the main aspect that allows everything to work. There isn't yet a name for this principle. The second part is the actual system, or the way of taking advantage of the algorithm overlapping property. The way I generated the overlapping combinations is by putting possible cases against the possible ways of cycling pieces. That is one way of using the property. There are likely other ways, such as making use of patterns and properties of the cube. These other ways would still be the union system and using overlapping algorithms, just a different way of generating the information.

Below are example images from how I developed CLL+1. This example is the no-swap Sune case. The columns have letter codes at the top. These are the possible edge cycles. CF means cycle the three edges on the f layer (UL, UR, and UF) clockwise, CA means a clockwise cycle of all edges, FBLR means swap the UF and UB edges and swap the UL and UR edges, and I stands for “infinity cycle” (this one does a cycle of UF->UB->UL->UR->UF). The numbers on the left are each of the 12 possible ZBLL cases for Sune. Inside the table are 1s and 0s. A 1 means that the edge cycle at the top of the table solves an edge for the case on the left side of the table. A 0 means that it doesn’t solve an edge for the case on the left side of the table. The red highlight means that the cycle is impossible for the corner case (You can’t clockwise cycle all edges for the normal Sune case for example). The numbers at the bottom of the table are a sum for each cycle at the top of the table. Almost every cycle solves an edge for 9 of the 12 edge permutations in each CLL case within ZBLL. Then there are others that solve an edge for only 3 of the 12 ZBLL cases. The next step is to find the combination of cycles that solves an edge for all 12 cases. That’s where the second image comes in. It is a chart that analyzes the first table and generates the possible unions. This is read by looking at single rows. The cycle FBLR (one of the highlighted blue cells in the diagonal line) can be combined with CF, CL, CB, CR, CCF, CCL, CCB, or CCR to successfully create a union that solves an edge for all 12 of the possible edge permutations for this no-swap Sune case. This can be confirmed by looking at the FBLR column in the first image and any of the CF, CL, CB, CR, CCF, CCL, CCB, or CCR columns. The 1s in any one of those secondary columns fills in the 0s in the FBLR column.

CLL+1: Solves the four LL corners and one edge. This was the first method developed using the union system. An interesting note is that it was developed by taking into account edge permutation only. Then an orientation trick outside of the system was used for the rest. It’s possible that if both edge permutation and orientation is incorporated into the cycle analysis that an even better result could be achieved. Possibly fewer cases and even better algorithms.

Snyder LL/Fish and Chips: Solves the four LL edges and one corner. Algorithms and a couple of ways to use this LL method already exist. But with unions, a better result would be achieved.

Tripod LL: This would be a direct solving version of Tripod LL. An algorithm would be used to solve a 1x2x2 block instead of the user building it intuitively.

22LL: This is an LL method that I proposed and had been working on years ago before the 22LL BLD algorithm set was released. The first step for this method is to solve any two corners and any two edges. Then finish with the last two corners and two edges. The 22LL that was released is intended for BLD and is the second step of this LL method. The first step, making it an actual LL method, can be solved using the union system.

OLLCP+1: This would be a combination of OLLCP and CLL+1. The corners are solved, all edges oriented, and a single edge is solved. Then all that’s left is a U-Perm. This would be a large number of cases (~660), but would likely be a good alternative for someone interested in learning full 1LLL.

LS+LL: Now it is possible to make new types of LS+LL methods. One type of LS+LL method could be to solve two corners and three edges as the first step, using an algorithm. The second step would solve the final five pieces. Or the opposite where you solve three corners and two edges as the first step. Another type of LS+LL method could be to solve a 1x2x2 block on the U layer as in Tripod LL, using an algorithm.

Situation Based Methods: This a new method proposal of mine and would be the optimal application of the system. In these methods, there wouldn't be predefined steps like OLL then PLL or CLL+1 then L3E. Instead, the LL method here would be a first step that uses the algorithm that produces the best result. This algorithm would set up for a second step that has a fast algorithm, a short algorithm, is easy to recognize, or any desired combination. The algorithm for the first step itself would also be optimized to contain these traits. This will produce an LL method that is computer optimized to be the fastest combination of steps while also containing a human manageable number of algorithms to learn, easy recognition, and easy recall. This wouldn't stop at LL methods. It can be applied to any step or group of steps. LSLL is another major application and there are many other methods with algorithm steps that could receive this benefit. There may even be situations where applying this to intuitive steps would produce good results. In this case it would be an analysis that was completed on the various possibilities within the intuitive step. This analysis would give the solver knowledge of which set of moves to solve a piece, pair, or block would produce the best results upon the other pieces that the solver is seeing in their lookahead. Many solvers are already deciding upon using different moves in order to influence surrounding pieces. So this would be the way to optimize that.

Intuition Reduction: Another interesting application would be to end every solve with an easy intuitive solution. Taking an edges oriented LL as an example, you could have an algorithm for each case or set of cases. This algorithm would reduce to one of several intuitive finishes. Endings such as R U' R', R U R', or R U2 R'. This would be versus learning all of ZBLL or using OCLL + PLL. So instead of methods always ending with algorithm based steps, they could end with a few moves that don't require any memorization and the final intuitive solution will be pre-known to the solver.

Big Cubes: New types of direct solving methods can now be created. Ones that require fewer moves compared to the methods that we have today. In K4 for example, multiple LL edges could be solved at once. Another option for K4 could be an LL method similar to the 3x3 LL methods above. Such as a method that solves two corners and two edges then the remaining two corners and two edges. Or, for other big cube methods, groups of centers and edges solved with an algorithm.

Megaminx: Just one example would be an LL method with a first step that solves two corners and three edges. Then the second step solves the last few pieces. Or the opposite version of this LL method where the first step is to solve three corners and two edges. The 3x3 LL methods above can also be applied to megaminx.

Other: There are many possibilities. You can now think of new types of methods or use ideas that you threw away because the traditional way of case calculation showed a very large number of cases. This not only applies to 3x3 and big cubes, but any puzzle. There are larger applications beyond just the primary algorithmic steps of methods. There may be ways to apply this during inspection by planning the manipulation of corners and edges in some way. This would likely consist of a series of intuitive moves. For application to a single piece type, such as just corners on a 2x2x2, it would be used in a way where different operations are being performed on various corners. Not just orienting all or permuting all, but orienting some in a certain direction while permuting others. Unions may also be useful for calculating certain types of numbers that someone is interested in knowing. I wonder what the equivalent would be for God’s/Devil’s Algorithm, God’s/Devil’s Union.

+ Pieces don’t have to be separated into primary and secondary pieces. It depends on the intention of the method being created. This means step 1 and 2 can be combined. Then step 3 would be to find the cycles for the group of pieces instead of a single type or set. For very complex applications, there may be more than two types of pieces involved, so they would be grouped according to what is to be accomplished. Grouping or splitting steps like this would be the same system and is actually the real version of the system. Steps 1 and 2 presented above are separated the way they are to make it easy to get started. Another reason is that many methods involve solving a larger group of pieces of one type and a smaller group from another type. When the steps are grouped for more advanced methods, the yield would likely not be a union. It could be a single algorithm that solves the intended set of pieces. An example would be if you were to input every LL case, with each case being the entire group of four corners and four edges. Then test the cycles against each case to solve something like any two corners and any two edges. The result would then be a single algorithm for that LL case. The system's ability to provide a single set or to show any overlap, the unions, is what makes it useful. So, the name Cycle Union System was chosen.

+ It is possible that a method would be more complex than the examples presented above. This method may require branching decisions. So the unions may contain more than just a few sets or could even be something similar to an Euler diagram where an algorithm set doesn’t overlap with the rest of the overlapping sets. For the very complex applications, it’s possible that a 3D array may be the best way to achieve the desired results.

+ The system can be applied recursively. If there is another group of pieces within the group of pieces to which you are already applying the system, this subgroup can also have the system applied. In the ZZ Discord server, speedsolving.com user Sosimomonon suggested LL methods where part of an algorithm is performed, another algorithm is performed, then the remaining execution of the original algorithm is completed. If the original algorithm is from a set where the union system was applied and the cases to which that sub-algorithm belongs would also would benefit from the system, then the system can be applied recursively. In this application, there would be sets/unions within sets/unions. This recursive property can be applied to the whole puzzle if desired, creating many layers of sets/unions.

+ A program could likely be built that allows users to input the set of pieces that they wish to solve. The program would then identify all of the possible cases and cycles. Then it would produce a union report showing which combinations of cycles solve each set of cases. All the user would then have to do is generate the algorithms. If anyone has interest in designing a program like this and you feel like you need assistance with understanding the system in some way, feel free to contact me.

+ For memorization, users aren’t actually always learning all of the possible cases and memorizing an algorithm for each case. It is much easier than that. Users will know each of the possible cases and will simply associate the few algorithms within the union to the correct cases. In this way, recall is easy. It is even better when one cycle solves a large number of cases and another cycle solves the remaining few. In COLL+1 for example, for each of the 12 possible edge permutations one cycle typically solves 9/12 of them. Then another cycle solves the remaining three. So this makes it easy for users to focus on identifying whether or not they have one of those three cases or not. Those three cases may stand out recognition-wise. If the user sees that they don’t have one of those three, they will know to use the other algorithm.

+ Recognition can be adjusted to the user’s liking. When building the cycle simulations, you don’t have to recognize or use all of the secondary pieces identified in step 2 of the process. If you have an LL method where you just want to create a single pair on the LL using an algorithm, this means you could solve one corner and one edge by only looking at UFL+UF+URF+UR+UBR. Versus recognizing the full LL. This makes it so that users aren’t recognizing many pieces at once. The downside is that the maximum number of pieces won’t be used and that you can’t take advantage of all situations. Find what works best for the method you are making.

+ The system is flexible. To use 22LL as an example, the first step would be to solve two corners and two edges. Which two corners and which two edges do you want to solve? Do you want to solve any two corners and any two edges in any position? Or do you want to be specific and solve only two adjacent corners and two edges within those two corners? During step four of the process, finding the unions, you can focus on and filter the cycles that solve pieces in the way you have specified.

+ Comparisons to LL systems: There exists Petrus 270 and Kirjava’s Duplex (which is Petrus 270 but for misoriented edges). There is also SIMPLE, which is a way to use Fish and Chips. The algorithm union property, and the union system, isn’t completely the same as these LL systems, but the difference will be described because comparisons may eventually be made. Petrus 270 and Duplex find two short and fast algorithms that can be executed one after the other to solve a single case. The first algorithm has the goal of putting the LL into one of several states. It doesn't completely solve the problem of direct solving mixes of piece types. These systems had the goal of combining two different fast algorithms to solve the last layer. There was no further identification of applications outside of that purpose. These systems were applied across the LL cases to determine the LL state that each alg produces. Kind of like algorithm crossing. The union system doesn't require having a computer apply algorithms over an algorithm set to see the results. Everything is achieved in a simple way through the properties and patterns of the union table. The union system is also more flexible as an overall concept in that it not only can be used to achieve the two-algorithm goal of Petrus 270, but also includes the discovery of three inter-connected elements: The algorithm union property, the simple piece cycling and table creation system that provides a way to make any method work and anyone can use the system, and the ability for it to achieve any possible state through state transformation. It can be applied across the entire puzzle among any group of pieces. SIMPLE is a method for reducing the number of cases required for the Fish and Chips LL method. It isn’t an algorithm overlapping system. It uses algorithms which apply to particular situations in combination with the solver’s thinking abilities. The union system looks at a group of pieces, large or small, and finds sets of algorithms. One or more algorithms within the set will solve part of that group of pieces and the remaining algorithms will solve the rest. Or an algorithm may have the ability to solve an entire group. Algorithms will usually also have the ability to solve some of the same cases within the group of pieces. However the key is in the difference between or among the cycles within the union. Additionally, this isn't only an LL system. It is applicable to any arrangement of pieces in any location.

Last edited:

Athefre

Member
To put this really simply: Using this system allows you to make methods with many fewer cases than what was previously thought. This is accomplished without adding any moves or thinking time during a solve. It actually does a lot more, but that is the main point for those interested in the speedsolving applications.

I know the main post was a lot to read, so I grouped things into spoiler tags. But I want to stress that this system solves two problems at once. The first is that it solves the long-standing direct solving method problem. Meaning how to solve a random set of pieces from a group into a desired position. The second is the case reduction (or, really, it reveals the true number of cases). Below are two examples from the past where someone proposed an idea, but the number of cases seemed like too many. Notice in both of these proposals that the proposers used tricks because the situation is complex.

"Little J": This one is essentially a subset of the 22LL LL method I talked about in the main post. The first step solves two adjacent corners and the two edges between them. You can see that people estimated the number of cases to be ~600. Using the cycle system, my estimation is that it would really be fewer than 100 cases. CLL+1 solves five pieces (four corners and an edge) in 166 cases, so two corners and two edges would be fewer than that.

"CLL+2": This was proposed by PapaSmurf in the CLL+1 topic. It solves CLL and two edges for methods where the LL edges and the FR slot are yet to be solved. The estimation here was 1,000-2,000 cases. Using the cycle system, I estimate that it would actually be around the same number of cases as CLL+1. So, fewer than 200.

PapaSmurf

Member
This weekend I'm going to give this a try to see if I can come up with anything better than current ZZ LSLL.

Athefre

Member
This weekend I'm going to give this a try to see if I can come up with anything better than current ZZ LSLL.

There are so many possible LS+LL methods that haven't been thought of. The chance that there are many better methods is so much higher than the chance that the best we have now is the best that there ever will be.

Athefre

Member
Go for it. I'll assist in any way that I can.

PetraPine

Member
Might be able to gen better modern waterman and OREO algs with this method, if anyone uses/wanted to develop waterman more

Athefre

Member
Might be able to gen better modern waterman and OREO algs with this method, if anyone uses/wanted to develop waterman more

There are definitely a lot of Waterman applications with so many edges to work with. Most notably probably being the steps of solving a few redges and the UL edge. Currently there are so many cases for that, but that could be cut down a lot using the system. Efficient edge manipulation can also now be done during Waterman CLL.

OREO is the new name for Redge + M-Slice EO right? That wouldn't fit the criteria. This system enables users to improve or make new methods where there is freedom of choice. In CLL for example the goal is to solve all four corners. There is no choice but to solve all four. But if you were trying to solve just two corners, then the system would allow you to solve any two corners from the set of four. Users don't have to choose two specific corners. That's just a very simple example. In OREO the only edge choice is UR and the goal is to orient all edges. If you wanted to make a new method for the last step of Waterman, examples would be something like the first look being EO + any edge or solve any two edges.

Member
Woohoo! this would be very helpful for my Fireman method, particularly the 3 redges algorithmic step

Athefre

Member
Woohoo! this would be very helpful for my Fireman method, particularly the 3 redges algorithmic step

It would definitely reduce the number of cases to something very easy to learn. What is the recognition style for the three redges when done using an alg? Do you look at all nine edges or a subset? Either way, the number of cases would be much fewer and better algs would be produced.

Member
It would definitely reduce the number of cases to something very easy to learn. What is the recognition style for the three redges when done using an alg? Do you look at all nine edges or a subset? Either way, the number of cases would be much fewer and better algs would be produced.
Yup, I was looking to reduce the number of alg, ye 3 edges in 9 positions, when the edges are oriented, I haven't made the recognition system but you should be able to figure it out easier than when the edges are not oriented.

PetraPine

Member
Woohoo! this would be very helpful for my Fireman method, particularly the 3 redges algorithmic step
i looked at your fireman post and had no understanding of how to do it,
could you post a new explanation in the new method thread but with pictures of the steps?

qwr

Member
I have no idea what any of this means
maybe there is some analogy to group theory stuff idk I barely understood it when I took a class on it

Athefre

Member
I have no idea what any of this means
maybe there is some analogy to group theory stuff idk I barely understood it when I took a class on it

You don't need to know anything about group theory for this. It's just a new discovery that solves a very complicated problem.

Here is an example that helped someone in the Discord server understand. It is the CLL+2 idea posted by PapaSmurf. Imagine you have the LL and the FR edge slot unsolved. You want to solve the four LL corners and any two edges among the five remaining. You already know that there are 42 CLL cases. But there are five edges and you only want to solve any two of them. How do you do that? You could pick two slots such as the FR slot and the UF slot for each CLL orientation. If you start counting the number of cases for that, you're going to immediately throw that method idea away. But it turns out that this problem can be solved, giving us many more method ideas to explore. For each CLL case, you take every possible case for the five edges and put them in the rows of a table. Then you take every possible way of manipulating those edges and put that in the columns of a table. Then, for each edge case, you check whether each type of manipulation solves two of the edges. It will likely happen that one of those ways of manipulation will solve two edges for every single case. If not, it will solve two edges in a majority of the cases. Then another way of manipulation is able to solve the remaining cases. So now you only have one or two algs to learn versus the much larger number that was thought before.

qwr

Member
ok I thought people just used cubeexplorer and commutators to find algs

PapaSmurf

Member
This isn’t to find algs, it’s to find cases.
Also, would be nice if someone good with computers could write some code that would do this.

Athefre

Member
I've thought a lot about the program for this. I detailed a bit in the main post what it would be able to do. I just don't have the programming or group theory knowledge to be able to make it. I have the vision for the features and have even drawn a design for the UI. It's just I would need to learn a lot to actually make it. If someone else is interested in making it, that would be amazing. A program would be what really shows how this system will change things and allow for better methods than what we have now.

Right now I'm using Excel to build simulated LLs and formulas to cycle pieces. It's a lot of work doing that for individual methods, so a program would be very helpful.