Algorithm Unions: A New Approach to Method Development

[abunickabhi]

Nice idea @Athefre. Maybe extending this to other methods than you mentioned can be a future task. I did not understand the program you intended to make. Are you saying maintaining an Excel sheet for all the cases is time consuming?

 

[qwr]

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.

I would help you if I understood what this method is but I still use 4LLL and I dont even know all the f2l cases so this is way beyond my cubing knowledge

 

[Athefre]

Nice idea @Athefre. Maybe extending this to other methods than you mentioned can be a future task. I did not understand the program you intended to make. Are you saying maintaining an Excel sheet for all the cases is time consuming?

There are two big things that have to be accomplished that make a program a necessity. The first is the calculation of the cases against the possible "cycles". The second is actually finding all of those cycles. I was able to apply the system to CLL+1. That was a very large task, but it pales in comparison to almost everything else.

For example, let's look at an LSLL method that PapaSmurf was talking about. Solving the five edges and any two corners in one alg. There are so many corner cases that it would be extremely time consuming to manually make the tables. The user also has to ensure that they have found every possible way of cycling the corners. Miss just one and it's possible that the one that was missed is an extremely key cycle. Like the number of cases, there is also a huge number of possible cycles. Also, even if someone spent the time putting all of this into Excel, the calculations would be extremely slow. Every cycle has to be simulated against every case. There are ways to reduce that, such as ignoring impossible cycles like an edge 3-cycle when two corners are swapped.

For CLL+1, it was 83 tables, 83 maps, 2,000 generated unions, and 12,000 individual simulated cycles. All done manually. I used a lot of formulas to make the task a little easier, but it was still three months of work. Imagine a method with many more cases and cycles.

The system has to instead be used as an algorithm for it to be efficiently applied. I have talked to mDiPalma and he said it could be implemented into HARCS. So we are thinking about how to get that working.

I would help you if I understood what this method is but I still use 4LLL and I dont even know all the f2l cases so this is way beyond my cubing knowledge

It is pretty difficult to understand. When I discovered this, it took me a long time to figure out how to put everything in words.

 

[qwr]

as a personal coding project to practice C++ OOP I think it would be fun to create a cube simulator that can handle arbitrary puzzles. ofc with specialized methods for certain common puzzles.

 

[Athefre]

I recently had another method idea for which this could be used.

We can create custom, situation-based methods. These methods can be designed for low move-count, easy recognition, best algs, or any combination. Instead of steps always being the same, the steps would vary based on the current overall case. For example, imagine you've gotten to LL and you usually do CLL+1 then L3E. However, maybe analysis has shown that for a certain group of cases under which the current case falls it would instead be faster and more efficient to solve the case into an L3C state.

So a large scale analysis would be done for LL, LSLL, and anything else. The best paths would be identified for groups of cases. Users would know algorithms from several methods including CLL+1, OLL, 22LL, ELL, and so on. Users wouldn't know every algorithm from these sets - only whatever has been identified as part of this situation-based method. Users would be able to execute the best overall set of moves for each situation.

I'll add this concept to the main post. I have to get this program made. Whether that means the system becomes incorporated into HARCS, I find time to relearn programming and study group theory, or by some other method.

 

[PapaSmurf]

This is optimised option select and is pretty cool.

 

[TheSlykrCubr]

I recently had another method idea for which this could be used.

We can create custom, situation-based methods. These methods can be designed for low move-count, easy recognition, best algs, or any combination. Instead of steps always being the same, the steps would vary based on the current overall case. For example, imagine you've gotten to LL and you usually do CLL+1 then L3E. However, maybe analysis has shown that for a certain group of cases under which the current case falls it would instead be faster and more efficient to solve the case into an L3C state.

So a large scale analysis would be done for LL, LSLL, and anything else. The best paths would be identified for groups of cases. Users would know algorithms from several methods including CLL+1, OLL, 22LL, ELL, and so on. Users wouldn't know every algorithm from these sets - only whatever has been identified as part of this situation-based method. Users would be able to execute the best overall set of moves for each situation.

I'll add this concept to the main post. I have to get this program made. Whether that means the system becomes incorporated into HARCS, I find time to relearn programming and study group theory, or by some other method.

ollcp+1 next, i guess

 

[Escher]

I recently had another method idea for which this could be used.

We can create custom, situation-based methods. These methods can be designed for low move-count, easy recognition, best algs, or any combination. Instead of steps always being the same, the steps would vary based on the current overall case. For example, imagine you've gotten to LL and you usually do CLL+1 then L3E. However, maybe analysis has shown that for a certain group of cases under which the current case falls it would instead be faster and more efficient to solve the case into an L3C state.

So a large scale analysis would be done for LL, LSLL, and anything else. The best paths would be identified for groups of cases. Users would know algorithms from several methods including CLL+1, OLL, 22LL, ELL, and so on. Users wouldn't know every algorithm from these sets - only whatever has been identified as part of this situation-based method. Users would be able to execute the best overall set of moves for each situation.

I'll add this concept to the main post. I have to get this program made. Whether that means the system becomes incorporated into HARCS, I find time to relearn programming and study group theory, or by some other method.

I really like this "bag of tricks" concept for (LS)LL. Particularly the idea of collecting situations according to ease of recognition - that's a super-interesting avenue to my eyes. I bet there are some fairly novel or obvious patterns which could become usable sets.

As regards the existing recognition systems, I imagine it's feasible to use a few different ones - 6-piece EO, phasing, 4/5-piece CLL, 4th slot, etc - and take a probabilistic approach. I.e. "It's typically better to use so-and-so approach when (some subset of) the last 10 pieces are in this sort of arrangement". I could see how using lots of components would mean that recognition, algorithm-learning and maintenance costs wouldn't be as high, in comparison to adopting a single large/advanced method, yet you'd be hitting significantly better 'routes to solved' significantly more often.

 

[Athefre]

I really like this "bag of tricks" concept for (LS)LL. Particularly the idea of collecting situations according to ease of recognition - that's a super-interesting avenue to my eyes. I bet there are some fairly novel or obvious patterns which could become usable sets.

As regards the existing recognition systems, I imagine it's feasible to use a few different ones - 6-piece EO, phasing, 4/5-piece CLL, 4th slot, etc - and take a probabilistic approach. I.e. "It's typically better to use so-and-so approach when (some subset of) the last 10 pieces are in this sort of arrangement". I could see how using lots of components would mean that recognition, algorithm-learning and maintenance costs wouldn't be as high, in comparison to adopting a single large/advanced method, yet you'd be hitting significantly better 'routes to solved' significantly more often.

Hey! It's been a while.

They will likely be pretty complex methods to develop when trying to sort based on recognition or any metric. Your idea of using a variety of recognition methods may be the way to go. It may turn out that grouping like this is what matches the system. For development of the methods, what I'm imagining is all of the possibilities having been analyzed and produced by the program. Users can then sort the information/combinations by categories to create a custom situation-based method that is catered to what they like in a solve. Their alg combinations could be focused on the best recognition, shortest algs, or some kind of determined overall good combination.

ollcp+1 next, i guess

For a while I was kind of thinking that developing OLLCP+1 would require an even larger simulator than what I built for CLL+1. Actually though, the work for OLLCP+1 is already done. The same combinations that work for COLL+1 can be applied to OLLCP+1. Find an OLLCP alg that cycles edges one way and another OLLCP alg that cycles in a way that combines with the first alg. There are many combinations available and that gives a lot of options for algs. All of the possible combinations are listed in the development files in my CLL+1 post, so anyone can use that to make OLLCP+1. I have read that the algs for OLLCP aren't very good. I wonder if that is due to not many people putting effort into finding great algs or if it is the nature of the LL method. As I talked about in the main post, OLLCP+1 may be a good alternative to 1LLL. It is 660 algs that always end in either a U-Perm or a skip versus ~4000 algs for 1LLL. The benefit of OLLCP+1 over CLL+1 would be the increased L3E skip chance. It also really depends upon the quality of the algs.