The New Method / Substep / Concept Idea Thread

[efattah]

For the record I will name the variant I suggested Roux-LSS (=Roux, Last Slot Skip). Just to re-iterate:
- FB
- Back right 2x2
- Pre-locate FR edge for L5C algorithm
- Execute L5C algorithm which auto-solves last slot because FR edge was pre-located
- L6E

According to the 2x2 L5C thread there are 486 cases for L5C including CLL, TCLL+, TCLL-. I'm not sure where the number 614 came from, or which is correct.

CubeBlazer's Zibber-b LSLL variant sounds promising but I'm not that familiar with Zipper-b.

 

[PapaSmurf]

Zipper is where you solve F2L minus an edge, then you either do CFRLL (CLL ignoring the FR edge) then L5E, or you do OLLCP then L5EP.
EO solved L5C will be less efficient than without EO solved then L5EP is equal to L5E in terms of movecount.
For 614: there are 2 sets of L5C: corner in slot and corner out of slot. Alg count for corner in slot is (43*3=)129. For corner out of slot, there are 27 orientations for every orientation of the D corner, so that's (27*3=)81. For each of those cases there are 6 CPs, so (81*6=)486. Then add 129 and 486 together to get 615. One of those is the solved case, so 614.

 

[CubeBlazer]

For Roux-LSS, it's not just TCLL. It literally would be my other method which I'm genning algs for (haven't got a name yet;

Spoiler: Method Description

The steps are:
Cross
F2L-1
COLS(LS+CO
CPELL(COALL
I'm genning COLS, Manchot already has a site with CPELL

COLS alone has around 1100 algs, while with Roux-LSS, that adds another 2 cases to deal with, which brings it up to around 1150 algs, which is not very good with a Roux start and end.

 

[CubeBlazer]

Even though I'm genning algs for "my" method, my method is still more viable because almost all algs are genned for the Partial set (just need to gen the flipped FR cases, I'm pretty sure the ZZ-C LS algs are optimal already; it's called the Partial set because you can rotate and use lefty qlgs), but for the full set, another 567 algs need to be genned. For Roux-LSS, it would be another 675 cases (without M setups to other cases in M slice) and that ignores CP. Unless you would do CP afterwards, the alg total would be raised once again. Because COLS didn't include CP(it's only CO), it gets to the point where there are 10,000+ algs.

Edit 1: My math is wrong, I did 27*21 additional algs for "my" method when it really is ((27*15)+(8*6)), but my math is also wrong between the difference of Roux-LSS and COLS. It's actually another 372 algs.
Edit 2: Just figured out my method is 959 algs. 802 for COLS, 157 for CPELL(COALL - Genned and published by Cubeur-Manchot). Also, it's not even my method, it was Blah's idea back in 2009, but work didn't start until earlier this year

 

[efattah]

I'm getting confused. For Roux-LSS, L5C has 614 cases and the pre-located edge does not add any algorithms. So the number of algorithms is the usual number of Roux algorithms +614 (L5C) minus 42 (CMLL) = Usual Roux +572.
This is for the case where you cannot skip the last slot if the FR edge is already in place without the FR corner also in place.

 

[CubeBlazer]

You said prelocate and solve both at the same time and it got me confused lol. If you're setting the case up, why not just use comms to solve the whole thing? You could do L5C into a 3style comm to prevent getting 6flips

 

[PapaSmurf]

You said prelocate and solve both at the same time and it got me confused lol. If you're setting the case up, why not just use comms to solve the whole thing? You could do L5C into a 3style comm to prevent getting 6flips

That's slow and less efficient.

 

[Skewbed]

How about doing FB, SB minus the FR edge, set up the FR edge with <MU>, CMLL that solves FR, then L6E.

It's the same alg count as CMLL, with more efficient algs than CMLL because of more unsolved pieces and possible positions for FR.

Although it might be slower because of the FR edge setup.

L5C is probably better, but worse recognition and more algs.

 

[Sue Doenim]

Here's an interesting idea that I don't think I've heard before: CLS, but you also permute the corners at the same time. If you attach the corner to the edge before inserting, disregarding the edge's orientation, you have about 3 times the alg count of any other CLL-type method. It would only save a few moves though. I don't know if it would be worth it.

 

[CubeBlazer]

That's called CPLS, but if you attach the corner, it would be 5000+ algs probs

 

[KAINOS]

Not an actual new method or anything, but I found out that doing <R, U> scambles on a cube then <L, U> scrambles doesn't affect CP state - in other words you could solve LB first with <L, U> (not using reverse scramble) and the rest of the cube would be still in <RU> 2-gen solvable state. Maybe this could open up to a possibility for new CP-first method...or not

Edit: I guess it might work on leor, if you do CP then <L, Lw, U> FB and the rest within <R, Rw, U> moveset. I'm not sure if it would be actually worth it though?

 

[KAINOS]

Yay for double post

Possibly the most impractical subset/concept ever proposed in this thread, but anyway my idea is: 2-gen 1-look LSLL. Alg count is ~1600 (84 2GLLs, <100 each for two T2GLL sets, and 1296 for the rest) which is quite a lot for sure. Still it's cool to see that 1LLSLL can be done with algs less than half of 1LLL for normal CFOP. (3915 algs)
One of the possible ways to make this actually viable would be to have some corner control before finishing the F2L-1, for instance making sure at least 2 of the corners are oriented. I think it would be possible to cut down the alg count to ZBLL level with that kind of case restriction, which is already proven to be humanly possible to learn and use (still very difficult though.)
Maybe you could use it together with CP-Leor I mentioned in the previous post?

Edit: Never mind, looks like my calculations were way off

 

[ImmolatedMarmoset]

I was thinking we should probably concoct a wiki page for LEOR so that all of the info about it can be in one place. That would be really useful for people who are thinking about switching, like myself. (There’s a very good chance I won’t, but there’s a chance I will if I try it out and like it.) Also, does anyone know optimal human movecount for each step?

 

[PapaSmurf]

I was thinking we should probably concoct a wiki page for LEOR so that all of the info about it can be in one place. That would be really useful for people who are thinking about switching, like myself. (There’s a very good chance I won’t, but there’s a chance I will if I try it out and like it.) Also, does anyone know optimal human movecount for each step?

It probably wouldn't be too hard. Also, 7, ?????, 12, 16 ish depending on algs.

 

[KAINOS]

I was thinking we should probably concoct a wiki page for LEOR so that all of the info about it can be in one place. That would be really useful for people who are thinking about switching, like myself. (There’s a very good chance I won’t, but there’s a chance I will if I try it out and like it.) Also, does anyone know optimal human movecount for each step?

It probably wouldn't be too hard. Also, 7, ?????, 12, 16 ish depending on algs.

I ran some solves on HARCS and the average movecount for EO+DFDB (stepwise optimal) was ~10.6, while optimal for the whole step was ~8.0. (Both in <RrUM> moveset and STM metric)
I think finding optimal solution for both EO and DFDB shouldn't be too difficult. Plus you can influence DFDB pieces during EO and also cancel some moves, so I'm guessing the number will be somewhere in 9.5-10 range.
(I only did 30 solves, though, so the numbers could be off by a good bit.)

 

[ImmolatedMarmoset]

I ran some solves on HARCS and the average movecount for EO+DFDB (stepwise optimal) was ~10.6, while optimal for the whole step was ~8.0. (Both in <RrUM> moveset and STM metric)
I think finding optimal solution for both EO and DFDB shouldn't be too difficult. Plus you can influence DFDB pieces during EO and also cancel some moves, so I'm guessing the number will be somewhere in 9.5-10 range.
(I only did 30 solves, though, so the numbers could be off by a good bit.)

So then we have like 7+10+12+16 which is ~44 movecount but the last step is algorithmic so it would be quite fast (not to say that LSE isn’t fast)

 

[Cubinwitdapizza]

I want to know if anyone has thought of this and also can someone tell me how to use an alg generator?

So basically this is very similar to vandenbergh for squan. Steps:

1. EO and placing E layer edges into correct place (or one bar a R2 away from being solved).
2 CT: this is where you basically see what corners have colors other than yellow on top and twist them. I need to generate algs for this because I have not found an efficient way to do this.
3 CO. This doesn’t have to be explained
4 EO (but like squans EO). You basically just do M2’s and M’ U2 M to put the yellow/white edges in the correct place.
5 CP. you basically do it the same as squan but again need to generate algs for it because some don’t work on 3x3.
6 EP. You permute edges simultaneously on each side. Need to generate algs.

You could also combine CP and EP by doing a PLL on each side or making an alg that solves both sides.

Also in the middle of that somewhere after CO EO you need to do R2 U2 R2 to flip the bar. This also swaps the FU piece and the BU piece. So ya just please at least send me a link to a video on how to generate algs. Now this might not be very speedsolving efficient but it’s basically just something I wanted to share.

 

[PapaSmurf]

I want to know if anyone has thought of this and also can someone tell me how to use an alg generator?

So basically this is very similar to vandenbergh for squan. Steps:

1. EO and placing E layer edges into correct place (or one bar a R2 away from being solved).
2 CT: this is where you basically see what corners have colors other than yellow on top and twist them. I need to generate algs for this because I have not found an efficient way to do this.
3 CO. This doesn’t have to be explained
4 EO (but like squans EO). You basically just do M2’s and M’ U2 M to put the yellow/white edges in the correct place.
5 CP. you basically do it the same as squan but again need to generate algs for it because some don’t work on 3x3.
6 EP. You permute edges simultaneously on each side. Need to generate algs.

You could also combine CP and EP by doing a PLL on each side or making an alg that solves both sides.

Also in the middle of that somewhere after CO EO you need to do R2 U2 R2 to flip the bar. This also swaps the FU piece and the BU piece. So ya just please at least send me a link to a video on how to generate algs. Now this might not be very speedsolving efficient but it’s basically just something I wanted to share.

SSC but worse.

 

[mDiPalma]

I want to know if anyone has thought of this and also can someone tell me how to use an alg generator?

So basically this is very similar to vandenbergh for squan. Steps:

I like your method.

HARCS can probably generate your algs. Post in the thread if you have questions.

 

[Zarxrax]

An idea for a 2x2x2 method popped into my head today. It's just a rough concept at the moment, and I'm not completely sure it would actually work or would be feasible. My idea was to create a method that has a fairly low alg count but is still possible to 1-look.

Step 0: Start with 3/4 of a face of opposite colors, similar to Guimond, but 2 of the pieces need to form a bar. This is usually solved already or can be solved with 1 move.

Step 1: The bar goes on the left side of the bottom. Then use 2-gen algs to orient. A caveat is that you can NOT use guimond-optimized algs for this step because pieces should not move between the bottom and top layers. I believe that with using 2-gen algs it should be possible to preserve the permutation of the pieces (or do a simple swap that is easy to track). I believe the alg count here should be 32 (8 cases + mirrors and inverses)

Step 2: Separation and PBL together. There are fewer separation cases than Guimond because you always have a bar on the bottom left. I think this might be 50-60 algs. More than I originally thought.

Potential cons of this method would be high move count, and AUF between steps might make the recognition more difficult. Plus, recognition of the cases for step 2 is apparently fairly tough as well.