Athefre
Veteran
- Joined
- Jul 25, 2006
- Messages
- 1,335
I have developed full L5C and an alternate L5C that I’m calling SL5C (Shortened L5C). The algorithms are developed to fit the following method:
- First block on the left.
- 1x2x2 on the right.
- L5C
- L7E
L5C: This is the complete set of 614 algorithms to solve all five corners in a single step.
SL5C: The other I’m calling SL5C (Shortened L5C). In SL5C the algorithms are reduced by 1-2 moves by having the algorithm be able to end in one of a few pseudo states - R U* offset, U R U* offset, U' R U* offset, or U2 R U* offset - or the solved state. The algs either naturally reach one of those states as generated or found by hand or it can be achieved by truncation - leaving out the last U* and R’ move in any algs that have that kind of ending. SL5C takes advantage of one of the strengths of L7E which is that the two remaining R layer edge positions can be either FR + UR or UR + BR and the corners don’t need to be perfectly solved at the start of L7E. So the corners can be in any of five states (the previously mentioned solved state in any AUF or the R U* offset, U R U* offset, U' R U* offset, or U2 R U* offset) and L7E still works as normal. This leaves the cube in the same pseudo L7E state that is in the 42 method but accomplished in fewer moves. The opposite of this could be developed as well, where the square is at dfR and the SL5C algs will often end with the two unsolved edge positions at FR and UR.
I guess the concept used in SL5C could be considered Inverse Transformation, the opposite of transformation. Instead of setting up a pseudo state then having an alg that solves the corners relative to the pseudo state as in transformation (such as 42), here the corners are starting from their natural state then an alg solves the corners to a pseudo state. This concept likely best applies to algorithm use. But it should work for some intuitive steps as well. Depending on the step on which this is used, it can reduce the movecount of the solve and allow the user to have better, more ergonomic algorithms. At first it is being applied to L5C and corner methods in general. However we may be able to find other applications besides just corners. With Zipper, it would be F2L-1 > SL5C > L5E or L5EP if used with ZZ. Though the L5E and L5EP angles need to be accounted for. With Waterman and other corners first related methods, it would be used during CLL, EG, L5C, or any other corner method. Waterman or WaterRoux in particular seems promising. The corner solution could leave out even more moves, keep the DBR corner (or any corner really) on the U layer, solve the two edges that go with that corner, then end with L7E.
L5C and SL5C movecount and MCC:
SL5C cases that benefited from the L5C truncation:
CLL: 27/42 (64%).
TCLL+: 34/43 (79%).
TCLL-: 34/43 (79%).
UO: 121/162 (75%).
U+: 128/162 (79%).
U-: 134/162 (83%).
Total 478/614 (78%)
I spent a lot of time testing every algorithm so that great ones would be provided in the document. I am just one person though. There are likely better algorithms for a lot of cases and the kinds of algorithms that people use change over time due to new ones being found, new fingertricks, and new hardware. I'm already looking back at the sets that I started with and wanting to regenerate. So through a community effort, we will be able to find even better algorithms.
Recognition:
I have also developed a recognition method which follows the below steps.
SL5C: The other I’m calling SL5C (Shortened L5C). In SL5C the algorithms are reduced by 1-2 moves by having the algorithm be able to end in one of a few pseudo states - R U* offset, U R U* offset, U' R U* offset, or U2 R U* offset - or the solved state. The algs either naturally reach one of those states as generated or found by hand or it can be achieved by truncation - leaving out the last U* and R’ move in any algs that have that kind of ending. SL5C takes advantage of one of the strengths of L7E which is that the two remaining R layer edge positions can be either FR + UR or UR + BR and the corners don’t need to be perfectly solved at the start of L7E. So the corners can be in any of five states (the previously mentioned solved state in any AUF or the R U* offset, U R U* offset, U' R U* offset, or U2 R U* offset) and L7E still works as normal. This leaves the cube in the same pseudo L7E state that is in the 42 method but accomplished in fewer moves. The opposite of this could be developed as well, where the square is at dfR and the SL5C algs will often end with the two unsolved edge positions at FR and UR.
I guess the concept used in SL5C could be considered Inverse Transformation, the opposite of transformation. Instead of setting up a pseudo state then having an alg that solves the corners relative to the pseudo state as in transformation (such as 42), here the corners are starting from their natural state then an alg solves the corners to a pseudo state. This concept likely best applies to algorithm use. But it should work for some intuitive steps as well. Depending on the step on which this is used, it can reduce the movecount of the solve and allow the user to have better, more ergonomic algorithms. At first it is being applied to L5C and corner methods in general. However we may be able to find other applications besides just corners. With Zipper, it would be F2L-1 > SL5C > L5E or L5EP if used with ZZ. Though the L5E and L5EP angles need to be accounted for. With Waterman and other corners first related methods, it would be used during CLL, EG, L5C, or any other corner method. Waterman or WaterRoux in particular seems promising. The corner solution could leave out even more moves, keep the DBR corner (or any corner really) on the U layer, solve the two edges that go with that corner, then end with L7E.
L5C and SL5C movecount and MCC:
SL5C cases that benefited from the L5C truncation:
CLL: 27/42 (64%).
TCLL+: 34/43 (79%).
TCLL-: 34/43 (79%).
UO: 121/162 (75%).
U+: 128/162 (79%).
U-: 134/162 (83%).
Total 478/614 (78%)
I spent a lot of time testing every algorithm so that great ones would be provided in the document. I am just one person though. There are likely better algorithms for a lot of cases and the kinds of algorithms that people use change over time due to new ones being found, new fingertricks, and new hardware. I'm already looking back at the sets that I started with and wanting to regenerate. So through a community effort, we will be able to find even better algorithms.
Recognition:
I have also developed a recognition method which follows the below steps.
- If the D layer corner is on the D layer, use CLL or TCLL recognition. If the D layer corner is on the U layer, determine the orientation of that corner.
- Find the orientation of three of the U layer corners that belong on the U layer. You can choose to always check the three that are on the U layer or any two on the U layer and the one that is currently on the D layer. Choose the positions that you want to check every solve.
- Recognize the pattern in those three corners from step 2.
L5C: This is the full 614 algorithms. It requires learning 614 recognition patterns and the full length algorithms.
SL5C: This is the same as L5C but with shortened algorithms.
CCMLL: This is used in the 42 method. A U layer corner is positioned above the right side 1x2x2 and an R turn is performed to make a pseudo CLL. The U layer corners are then solved using CLL or TCLL algorithms. This reduces the number of cases to 42 if an oriented corner is used or 168 if the corner is in any orientation.
My overall opinion: If you want the lowest movecount and the easiest recognition, SL5C is the best. If you want to learn as few algorithms as possible, CCMLL and the 42 method is the way to go.
SL5C: This is the same as L5C but with shortened algorithms.
CCMLL: This is used in the 42 method. A U layer corner is positioned above the right side 1x2x2 and an R turn is performed to make a pseudo CLL. The U layer corners are then solved using CLL or TCLL algorithms. This reduces the number of cases to 42 if an oriented corner is used or 168 if the corner is in any orientation.
My overall opinion: If you want the lowest movecount and the easiest recognition, SL5C is the best. If you want to learn as few algorithms as possible, CCMLL and the 42 method is the way to go.
- SSL5C: There is something about SL5C that I noticed. It seems to be that each case has a shorter or longer compliment version which is the same algorithm but with fewer or additional moves at the end. Example: The SL5C version of (U2) F U R U' R2 F' R U' R U2 R', (U2) F U R U' R2 F' R U' R done in reverse leads to a different looking L5C case. That case, after recognizing using NML5C, can be solved using (U') F U R U' R2 F' R, which is already a full L5C algorithm. This algorithm is the same as the original SL5C algorithm minus the last two moves. This might could be used as a memory aid to learn the two related algs in tandem. So the user would learn it as something like (U2) (U’) F U R U' R2 F' R U' R. This could cut down on the memorization effort. But it may also make recall difficult. This needs more research.
- Union L5C (UL5C): This is an L5C reduction method that I might finish development on sometime. The corners are reduced to the fully solved position, R’ away, U R’ away, U’ R’ away, or U2 R’ away from solved. It works by finding groups of four cases which can all be solved to those pseudo states using the exact same algorithm. The number of algorithms required to learn compared to full L5C is reduced (divided by 4) since the same algorithm will be used for four different cases. This reduction method is pretty much the inverse of CCMLL.
- I went down a long thought path of combining the technique of SL5C with UL5C and CCMLL. These various combinations lead to interesting variants on the number of algorithms required to be learned, the number of recognition patterns, movecount, and recognition style. All of these combinations don't go to any extreme outside of SL5C or 42. None of them have a lower movecount than SL5C and none have fewer required algorithms or patterns than 42.
- A long term plan is to incorporate pseudo L5C recognition into ACRM. This means the use of the L/R stickers for recognition when any right side 1x2x2 is allowed to be built.
- Currently the SL5C algorithms are the result of removing the final U*R' turns of an algorithm. Using a program which is able to solve to any input state, it may be possible to find even better algorithms by more often reducing to one of the five possible states as intended within the concept. Algorithms which reduce to the pseudo or solved state with the algorithms having any kind of ending such as F, F', R, and so on.
First block: 7 moves.
Square: 8 moves.
L5C: 10.47 moves + .75 AUF for standard L5C. 9.00 moves + .75 AUF for SL5C.
L7E: 17-18 moves. More advanced L7E methods or extensions to current L7E methods may be able to reach ~15 moves.
Total:
Square: 8 moves.
L5C: 10.47 moves + .75 AUF for standard L5C. 9.00 moves + .75 AUF for SL5C.
L7E: 17-18 moves. More advanced L7E methods or extensions to current L7E methods may be able to reach ~15 moves.
Total:
- ~43-44 moves with standard L5C and a standard L7E method.
- ~41-42 moves with SL5C and a standard L7E method.
- ~39-40 moves with SL5C and a more advanced L7E method.
- ~37-38 moves with SL5C, a more advanced L7E method, and pseudo blockbuilding (any right side 1x2x2).
- My L7E method: The extension of Roux LSE to L7E. Orient all edges using iterative EO, solve the three LR edges, then permute the M slice. The future plan is to develop an EOLR advancement.
- Shadowslice’s original L7E method: Orient all edges while solving the FR edge. Then finish with L6EP.
- An alternate L6EP reduction method
- FR + Arrow
- Crafto's L6EP reduction method
- WaterRoux L7E
Last edited:
