I think there's definitely improvements that could be made to the Lewis L5E algs, but I don't have any way to generate new algs. Does anyone know if there's something like cube explorer for 4x4 or 5x5?
 
This might have been proposed before but here it is anyway.

Build 2 1x2x2 blocks in DBL and DBR, and solve the DF edge
Solve the FL and FR slots using the M slice to orient the edges
Solve L9P (Last 9 Pieces) any way you want. I use CLL the L5E.
 
This might have been proposed before but here it is anyway.

Build 2 1x2x2 blocks in DBL and DBR, and solve the DF edge
Solve the FL and FR slots using the M slice to orient the edges
Solve L9P (Last 9 Pieces) any way you want. I use CLL the L5E.

It's pretty similar to Petrus-W. I'm not sure though about the DF edge. Why not insert the DB instead?
 
I think there's definitely improvements that could be made to the Lewis L5E algs, but I don't have any way to generate new algs. Does anyone know if there's something like cube explorer for 4x4 or 5x5?
There is ksolve++ for stuff like that, though instead of a full 4x4 or 5x5, defining only the M slice and U layer should be enough.
 
2x2 Method:

CPLine - Like Briggs and YruRU. This usually takes around 3-4 moves on 3x3, so it should be the same on 2x2
CO - Orient the Corners using <R, U>. Can usually be solved in 5ish moves
Solved - Solve a layer using <R2, U>. Most cases are 4-movers, with one being 6 and the worst being 9. This step can be executed really fast

Should average around 12 HTM, and almost all of it is either R U or R2 U


This could also be adapted for 2x2x3 by doing CPLine, Layer(also solving top layer), E-layer. CPLine is similar to Faces, Layer is <R2, U> and faster than PBL, and E-Layer is the same(although it could be influenced during the layer, where you can't easily influence the E-layer normally). Should be around 15 HTM, same as WoowyBaby's method
 
2x2 Method:

CPLine - Like Briggs and YruRU. This usually takes around 3-4 moves on 3x3, so it should be the same on 2x2
CO - Orient the Corners using <R, U>. Can usually be solved in 5ish moves
Solved - Solve a layer using <R2, U>. Most cases are 4-movers, with one being 6 and the worst being 9. This step can be executed really fast

Should average around 12 HTM, and almost all of it is either R U or R2 U


This could also be adapted for 2x2x3 by doing CPLine, Layer(also solving top layer), E-layer. CPLine is similar to Faces, Layer is <R2, U> and faster than PBL, and E-Layer is the same(although it could be influenced during the layer, where you can't easily influence the E-layer normally). Should be around 15 HTM, same as WoowyBaby's method
This has been proposed before, I think by @WarriorCatCuber.
 
2x2 Method:
Should average around 12 HTM, and almost all of it is either R U or R2 U
Sounds kinda sketchy, God's number for the 2x2 is 11. I think the actual movecount would be around 14. Could you do some example solves?

A 3-look method for LSLL+EO that can be 2-look with no more algs that I came up with:
1. Using WV, solve an edge and orient corners. 8 moves.
2. Solve the remaining corner using a commutator while influencing pll. 8 moves.
3. PLL. 12 moves.
Total: 28 moves.
Movecount when using ZBLL: 23
With some practice, you can do Steps 2 and 3 in one look. Recognition is also easier than ZBLL (imo). That makes this a 2-look LSLL+EO method that only uses 5 more moves than ZBLL and has better recognition. Are there any disadvantages to this method that I'm not seeing? If not, I will probably be switching to this for Petrus.
 
A 3-look method for LSLL+EO that can be 2-look with no more algs that I came up with:
1. Using WV, solve an edge and orient corners. 8 moves.
2. Solve the remaining corner using a commutator while influencing pll. 8 moves.
3. PLL. 12 moves.
Do you mean orienting all 8 corners, or just 3 of the top layer corners? If it's orienting all 8 corners, this step is TSLE (104 algs), which is good, but it has already been invented. After TSLE, the whole cube can be solved with TTLL (72 algs + PLL). Two-look TTLL with a comm+PLL is not a good idea, since the oriented corner comms all require a rotation, and R2 U2 R2 U' R2 U' R2 also inserts the last corner while giving a PLL.
If it's just 3 of the top layer corners, this is usually good, since the commutator can be used to orient the last two corners while inserting the final corner. However, if the white corner is twisted in place, this cannot be solved with one commutator, so you'll need to use one of 2 algs for those cases, then do PLL, which is inefficient. I'm not sure how many algs would be needed for this step, but you would need to know all 104 recognition cases, where one algorithm could be used for multiple cases.
 
Do you mean orienting all 8 corners, or just 3 of the top layer corners? If it's orienting all 8 corners, this step is TSLE (104 algs), which is good, but it has already been invented. After TSLE, the whole cube can be solved with TTLL (72 algs + PLL). Two-look TTLL with a comm+PLL is not a good idea, since the oriented corner comms all require a rotation, and R2 U2 R2 U' R2 U' R2 also inserts the last corner while giving a PLL.
If it's just 3 of the top layer corners, this is usually good, since the commutator can be used to orient the last two corners while inserting the final corner. However, if the white corner is twisted in place, this cannot be solved with one commutator, so you'll need to use one of 2 algs for those cases, then do PLL, which is inefficient. I'm not sure how many algs would be needed for this step, but you would need to know all 104 recognition cases, where one algorithm could be used for multiple cases.
Yeah, I mean just 3 of the top layer corners. If all corners happen to be oriented, you can do [R'DRU'RD'R'U, U], but since it has more moves it might be useful to do TTLL or the variation of TTLL that solves CP. To avoid white corner twisted in place cases, you could use summer variation instead of winter variation, or just do normal LSLL. Though there are 108 cases, there are only 54 algorithms you need to know as mirrors can be used. Due to the nature of winter and summer variation, you know which corner is going to be inserted with the edge, meaning you can predict which corner will be in the DFR position as well as what orientation it will be in, which allows for a very smooth transition into the commutator. You can also predict PLL before doing the commutator, which means that with practice, this can be a virtually pauseless LSLL+EO method. Is there anywhere I can find good summer variation algorithms?
 
Sounds kinda sketchy, God's number for the 2x2 is 11. I think the actual movecount would be around 14. Could you do some example solves?

A 3-look method for LSLL+EO that can be 2-look with no more algs that I came up with:
1. Using WV, solve an edge and orient corners. 8 moves.
2. Solve the remaining corner using a commutator while influencing pll. 8 moves.
3. PLL. 12 moves.
Total: 28 moves.
Movecount when using ZBLL: 23
With some practice, you can do Steps 2 and 3 in one look. Recognition is also easier than ZBLL (imo). That makes this a 2-look LSLL+EO method that only uses 5 more moves than ZBLL and has better recognition. Are there any disadvantages to this method that I'm not seeing? If not, I will probably be switching to this for Petrus.
This is just worse ZZ-CT. ZZ-CT does have more algs (197), but it is 2 look and does not require a corner to be paired with the E-slice edge when orienting.

ZZ-CT LSLL with EO Steps:
1. TSLE - Solve the E-slice edge while solving corners (Different than winter variation because it doesn't need a corner to be paired with an edge)
2. TTLL - Solve the rest of the Cube

If you are interested in learning this method, there are a few good resources out there.
 
This is just worse ZZ-CT. ZZ-CT does have more algs (197), but it is 2 look and does not require a corner to be paired with the E-slice edge when orienting.
You don't need to pair a corner with an edge, you just insert one edge while orienting 3 top layer corners.
 
2x2 Method:

CPLine - Like Briggs and YruRU. This usually takes around 3-4 moves on 3x3, so it should be the same on 2x2
CO - Orient the Corners using <R, U>. Can usually be solved in 5ish moves
Solved - Solve a layer using <R2, U>. Most cases are 4-movers, with one being 6 and the worst being 9. This step can be executed really fast

Should average around 12 HTM, and almost all of it is either R U or R2 U


This could also be adapted for 2x2x3 by doing CPLine, Layer(also solving top layer), E-layer. CPLine is similar to Faces, Layer is <R2, U> and faster than PBL, and E-Layer is the same(although it could be influenced during the layer, where you can't easily influence the E-layer normally). Should be around 15 HTM, same as WoowyBaby's method
CP line will take lesser moves on a 2x2x2, because no DL edge. I’d estimate 2-3 moves.
The orientation would take quite a few moves, I’m unsure how you intend to do it in 5 moves. There are hundreds of cases, so given only RU moves, it kinda gives a lower bound of 5 moves on average at the very best. My guess for the average would be 7-8 moves. So that’s an average of closer to 15 HTM.

A cool method to show off; but not 1-lookable; and RU isn’t that great a moveset on 2x2x2 so certainly not spread (edit:speed) solving viable.
 
Last edited:
spread solving
speed spreading.png
 
So, I had an idea, it's an extension of f2l blocks where you solve the 2x2x3 block with the 2x3 part on the Left, and then solve all of the edges and then orient and permute the corners, probably stupid but it doesn't sound too bad to me.
 
Back
Top