The New Method / Substep / Concept Idea Thread

[icestrike]

Im not sure if this has been said here before (i don't feel like going through 200+ pages) But I propose something for those solves where it is much easier to keep a cross edge flipped than it is to orient it.
So this will be a set of algs that orient the last layer, but also fix the cross edge. Cross edge is by default held in front, but by doing D moves can set up the cube into the right position to do the alg.

I'm sorry if this has been proposed already, but I really like this idea, as I think it has less algs than full oll. But, I haven't done the math(s) to see. And I can see some potential in it, as long as all the algs aren't terrible. I have two algs, but those are probably the best ones. One of them is a seven move M U alg, and the other is just a setup to F sexy F'. I'm thinking many algs will be just setup into an oll.

 

[icestrike]

Im not sure if this has been said here before (i don't feel like going through 200+ pages) But I propose something for those solves where it is much easier to keep a cross edge flipped than it is to orient it.
So this will be a set of algs that orient the last layer, but also fix the cross edge. Cross edge is by default held in front, but by doing D moves can set up the cube into the right position to do the alg.

I'm sorry if this has been proposed already, but I really like this idea, as I think it has less algs than full oll. But, I haven't done the math(s) to see. And I can see some potential in it, as long as all the algs aren't terrible. I have two algs, but those are probably the best ones. One of them is a seven move M U alg, and the other is just a setup to F sexy F'. I'm thinking many algs will be just setup into an oll.

oh I just realized this section is dead

 

[PapaSmurf]

I think it should have the same number of algs as OLL, although just solve the cross correctly. With full CN it would make this kinda redundant.

 

[PapaSmurf]

This is a serious idea that uses aspects of M-CELL and Zipper. I've called it Z-CELL (Zipper-CELL) temporarily, but that's not for certain at all.

Spoiler: Steps

Spoiler: First Block

1x2x3 block on the left, exactly the same as Roux. Average movecount of 7 and definitely speedsolving viable.

Spoiler: SBsqr

A 1x2x2 at RDB, just like Roux SB but only the back square. Average movecount of 6.8 which is imo achieveable, but if not, low 7s is definitely in human expectations.

Spoiler: DFDB

Solve DFDB and also all the centres. 5.6 average movecount and very easy to do optimally.

Spoiler: L5C

You solve the last 5 corners. Unfortunately there's an alg count of 614 algs, but fortunately an average movecount of about 10 (I dunno exactly because speed optimal algs don't exist. HARCS says 9.623 over 1000 solves). That is fortunate as the number of moves you have to learn is 6140. ZBLL is (14.5*493=)7148.5 moves, so technically it is less info than ZBLL. From what I can gather, recog should be fine.

Spoiler: L5E

This is where you finish the cube. The step has an average movecount of 11.09 ATM according to Justin Taylor's algs and has an alg count of 245. Apparently all the algs are good, as is the recog.

Spoiler: Stats

From the movecounts given (and AUFs) the method averages 7+7+5.6+10(?)+11.09+2.25=42.94. The first 3 steps are definitely speedsolving viable, as is the last one. L5C is a lot of cases to be going through at once, but again I think that it should be fine. It is also easier to lookahead from DFDB to this step than other non algorithmic to algorithmic steps as its majority slices. There are also 859 algs, but you need to memorise less info than ZB.

With this method, if you can get good at the blockbuilding first half but you also like algs, this method works well. It has a very low movecount and most likely a decent TPS. Any thoughts are welcome.

 

[ImmolatedMarmoset]

This is a serious idea that uses aspects of M-CELL and Zipper. I've called it Z-CELL (Zipper-CELL) temporarily, but that's not for certain at all.

Spoiler: Steps

Spoiler: First Block

1x2x3 block on the left, exactly the same as Roux. Average movecount of 7 and definitely speedsolving viable.

Spoiler: SBsqr

A 1x2x2 at RDB, just like Roux SB but only the back square. Average movecount of 6.8 which is imo achieveable, but if not, low 7s is definitely in human expectations.

Spoiler: DFDB

Solve DFDB and also all the centres. 5.6 average movecount and very easy to do optimally.

Spoiler: L5C

You solve the last 5 corners. Unfortunately there's an alg count of 614 algs, but fortunately an average movecount of about 10 (I dunno exactly because speed optimal algs don't exist. HARCS says 9.623 over 1000 solves). That is fortunate as the number of moves you have to learn is 6140. ZBLL is (14.5*493=)7148.5 moves, so technically it is less info than ZBLL. From what I can gather, recog should be fine.

Spoiler: L5E

This is where you finish the cube. The step has an average movecount of 11.09 ATM according to Justin Taylor's algs and has an alg count of 245. Apparently all the algs are good, as is the recog.

Spoiler: Stats

From the movecounts given (and AUFs) the method averages 7+7+5.6+10(?)+11.09+2.25=42.94. The first 3 steps are definitely speedsolving viable, as is the last one. L5C is a lot of cases to be going through at once, but again I think that it should be fine. It is also easier to lookahead from DFDB to this step than other non algorithmic to algorithmic steps as its majority slices. There are also 859 algs, but you need to memorise less info than ZB.

With this method, if you can get good at the blockbuilding first half but you also like algs, this method works well. It has a very low movecount and most likely a decent TPS. Any thoughts are welcome.

I like it but I am never going to learn it bc I hate algs

 

[efattah]

I like Z-cell but I would change it to skip the DFDB step; this will decrease significantly the number of moves for L5C because those edges don't need to be maintained. Then you end up with L7E which you can solve very efficiently with LMCF algorithms. In my opinion this modification to Z-CELL would significantly increase the efficiency.
Actually this could be an awesome method!

 

[PapaSmurf]

I thought about Roux but with L5C and L7E and it's only marginally better than CMLL->LSE unless you can somehow come up with a good way to do L7E that averages similar to LSE. Also, with the "decrease significantly thing", it's like 0.5 moves iirc, but maybe a little bit more. Anyway, this way of doing things is just using a modified SSF2L to end with the best LSL for CFOP.

 

[efattah]

L5C with a free M-slice is way more efficient than CMLL.
L7E is only slightly longer than L6E. In L7E, all you need is one of UL, UR, or FR to be random filled with an L/R edge which happens on most solves. In that case L7E is actually Waterman L6E which takes the same number of moves as Roux L6E except in most cases has higher TPS because RrUM has faster TPS than MU.

For Roux you would have to solve the last FR pair, THEN do CMLL which is a bad way to solve corners because it must preserve the M-slice. For Z-CELL, you SKIP the last FR pair AND save several moves on the corners solve, and then lose maybe 1.5 moves on average on L7E, the net result is a fairly large savings and an increased use of luck as well.

Taking a wild guess
Roux last pair: 5 moves
CMLL: 11.5 moves
L6E w/EOLR: 15 moves
Total: 31.5 moves

Z-cell w/L7E approach:
Last pair: 0 moves (skip)
L5C: 10 moves
L7E: 17 moves
Total: 27 moves (saves 4.5 moves over Roux with no loss of ergonomics or lookahead)

With Z-Cell, you would be able to look ahead to the L5C case as you are solving the back right pair, reducing recognition time.

 

[PapaSmurf]

L5C with a free M-slice is way more efficient than CMLL.

Doubt it's way more efficient.

L7E is only slightly longer than L6E. In L7E, all you need is one of UL, UR, or FR to be random filled with an L/R edge which happens on most solves. In that case L7E is actually Waterman L6E which takes the same number of moves as Roux L6E except in most cases has higher TPS because RrUM has faster TPS than MU.

I also doubt that RUMr has a higher tps than MU. Have you seen some Roux solvers lately?

For Roux you would have to solve the last FR pair, THEN do CMLL which is a bad way to solve corners because it must preserve the M-slice. For Z-CELL, you SKIP the last FR pair AND save several moves on the corners solve, and then lose maybe 1.5 moves on average on L7E, the net result is a fairly large savings and an increased use of luck as well.

Taking a wild guess
Roux last pair: 5 moves
CMLL: 11.5 moves
L6E w/EOLR: 15 moves
Total: 31.5 moves

Z-cell w/L7E approach:
Last pair: 0 moves (skip)
L5C: 10 moves
L7E: 17 moves
Total: 27 moves (saves 4.5 moves over Roux with no loss of ergonomics or lookahead)

It's more like: Roux - 7.5, 10.5, 11, which is 29. And the second method you just described is Roux just with more algs. Even if you did save the 4.5 moves, it would still be as efficient as Z-CELL.

With Z-Cell, you would be able to look ahead to the L5C case as you are solving the back right pair, reducing recognition time.

That's harder than doing it during DFDB. Basically, you described an advanced version of Roux that has no advantage over Z-CELL. I do think that FB, SBsqr, L5C, L7E should be explored, it's just that no one has found a good way to do L7E. Not waterroux or other ideas. The best IMO is to solve EO+one U edge then do conjugated L6EP, but that still is probably bad.

 

[efattah]

Doubt it's way more efficient.

I also doubt that RUMr has a higher tps than MU. Have you seen some Roux solvers lately?

It's more like: Roux - 7.5, 10.5, 11, which is 29. And the second method you just described is Roux just with more algs. Even if you did save the 4.5 moves, it would still be as efficient as Z-CELL.


That's harder than doing it during DFDB. Basically, you described an advanced version of Roux that has no advantage over Z-CELL. I do think that FB, SBsqr, L5C, L7E should be explored, it's just that no one has found a good way to do L7E. Not waterroux or other ideas. The best IMO is to solve EO+one U edge then do conjugated L6EP, but that still is probably bad.

I disagree that L6E-EOLR can be done in 11 moves on average, but even if it could, consider that in L7E, solving the FR edge directly never takes more than 7 moves. Solving FR directly then doing L6E is the dumbest and worst possible L7E method, but by that simple analysis it takes no more than 7 extra moves vs. Roux L6E-EOLR. Around 200 L5C algorithms have already been generated for 2x2 and are in active use, and they are a lot shorter than CLL/EG1 algorithms; but again even if you assumed the most skeptical possible scenario and assumed that L5C takes the same number of moves as CMLL, then as far as STM moves, the only difference between Z-cell and Roux would be that Roux takes 7.5 moves for the last pair while Z-Cell skips the last pair and solves FR in 7 moves or less; so even in the most skeptical of all possible scenarios, Z-cell takes 0.5 moves less, and in reality it would do a lot better.

The best method thus far to solve L7E is just the latest unpublished LMCF method of doing it. I'd be happy to bet anyone $100 on 50 scrambles that Z-cell with L7E takes 1.5 moves or less than Roux finishing the same solve.

One of the problems of L7E is the way we use to count the moves. Roux in general frequently has cases where you do [M'R'] or [MR] or [M2R] or [M2R'] at the same time. If you count M-R combos as one move for the entirety of the Roux solve, with a fictional 'STMR' metric, then L7E suddenly looks way more appealing because L7E heavily relies upon the [M'R'] or [MR] single move.

I didn't invent Z-cell, I'm just supporting a good idea that someone has put forward which is the best idea I have seen in years.

 

[Solvador Cubi]

Don't these discussions around "Z-Cell" remind me of the steps of 42 method:
https://www.speedsolving.com/wiki/index.php/42

I'm not familiar enough with either, but wanted to throw out that comment.

 

[efattah]

There are similarities with '42 Method' for sure.

I would throw out that some time ago there was discussion about the possibility of any method being sub-40 average movecount for a human. With Z-cell, you could, theoretically, increase the L5C algorithm count from 600 to around 3000. In this fashion I mean that you would inject M/M' moves and or transpose R to r and vice versa, like Waterman did with his advanced variant. Waterman's method was to inject M/M' or R->r during CLL, to affect the edges during the corner solve and solve 1 edge in the process. Roux now does similar thing with multiple CMLL's to affect edge orientation and avoid the 6-flip.

With Mega-Z-Cell, you would inject M/M' or R->r during the L5C algorithm to solve the FR edge at the same time as the corners. In this fashion the last Roux slot is essentially skipped with no added moves. I believe that would result in a sub-40 movecount speed solving method even though it would have 3000 algs. Jabari knows around 3000 algs for 1LLL, so not impossible. The drawback (not insignificant), is that with that method you would not be able to avoid 6-flips on L6E.

 

[PapaSmurf]

I disagree that L6E-EOLR can be done in 11 moves on average, but even if it could, consider that in L7E, solving the FR edge directly never takes more than 7 moves. Solving FR directly then doing L6E is the dumbest and worst possible L7E method, but by that simple analysis it takes no more than 7 extra moves vs. Roux L6E-EOLR. Around 200 L5C algorithms have already been generated for 2x2 and are in active use, and they are a lot shorter than CLL/EG1 algorithms; but again even if you assumed the most skeptical possible scenario and assumed that L5C takes the same number of moves as CMLL, then as far as STM moves, the only difference between Z-cell and Roux would be that Roux takes 7.5 moves for the last pair while Z-Cell skips the last pair and solves FR in 7 moves or less; so even in the most skeptical of all possible scenarios, Z-cell takes 0.5 moves less, and in reality it would do a lot better.

The best method thus far to solve L7E is just the latest unpublished LMCF method of doing it. I'd be happy to bet anyone $100 on 50 scrambles that Z-cell with L7E takes 1.5 moves or less than Roux finishing the same solve.

One of the problems of L7E is the way we use to count the moves. Roux in general frequently has cases where you do [M'R'] or [MR] or [M2R] or [M2R'] at the same time. If you count M-R combos as one move for the entirety of the Roux solve, with a fictional 'STMR' metric, then L7E suddenly looks way more appealing because L7E heavily relies upon the [M'R'] or [MR] single move.

I didn't invent Z-cell, I'm just supporting a good idea that someone has put forward which is the best idea I have seen in years.

2 things. Firstly, Z-CELL is the method described by me. What you're describing is an advanced form of Roux which would take off if L7E became viable, so call it the right thing. Secondly, please document your L7E idea properly because it could change Roux if it is good. If it isn't let's try to find a good one. Once we have (if we have to) we can then compare Z-CELL to this Roux variant. Also, thanks for the compliment! It's something that I've had in my head for a while.

Also, the 3000 alg idea isn't practical at all imo. The >800 algs is already pushing it.

 

[efattah]

I really like the idea of mixing in L5C with Roux. The method I use for L7E in the latest LMCF still isn't optimal, and so I was thinking about L7E skips and I think there is an option to force L7E skips without 3,000 algorithms.

Consider this modification to Z-cell:
1. When generating the 614 L5C algorithms, choose variants where the FR edge is dislocated/disrupted; this should not add any moves to the average since in almost every case the FR edge will be disrupted
2. For each of the 614 L5C algorithms, memorize the effect that it has on the FR edge; more specifically, memorize the starting location of the edge which ends up in the FR slot after the L5C algorithm (location + orientation)
3. Now solve first block, and back right corner.
4. We are now at the L5C step. Having looked ahead during solving of the back right 2x2 block, you know where the FR-destined edge is (in one of 7 possible locations); now use M/U moves to place that edge in the correct location such that it gets automatically solved by the L5C algorithm. According to my calculations the average number of moves this will take is about 4, with no case taking more than 5; however there is a 1 in 7 chance the FR edge is already in the FR slot which is a case we cannot easily resolve without learning another 614 algorithms
5. Do the L5C algorithm; now in 6 of 7 cases, you skip the FR edge
6. Finish with Roux L6E-EOLR

Using this method, 6/7 (85%) of the time we skip the FR edge and go directly to L6E. 1 in 6 (14%) we need to solve the FR edge after L5C. It is of course possible to learn 3 sets of L5C algorithms to deal with that 1 in 6 chance, but probably not worth it for most people.

So using this method, almost every solve you skip the last roux slot (7.5 moves average according to PapaSmurf), and that step is 'replaced' with pre-location the FR edge into the correct location such that it is automatically solved by the L5C algorithm, and that step takes around 4 moves average, so we dropped the move count by 3.5.

For the extremist who is willing to learn 1800 algorithms, you learn 3 variants of each L5C algorithm, the two additional variants deal with the case where the FR edge is already in the FR slot and oriented, the other case is where the FR edge is already in the FR slot and disoriented. While few people would learn all 1800 algorithms, those cases are crazy awesome, because if you knew the 1800 algorithms, then if the FR edge is in the FR slot (oriented or disoriented), you now get a full last-slot skip, since you do not need to pre-locate the FR edge and it is solved by the L5C algorithm variant. So in that case, you save a full 7.5 moves over Roux (plus, possibly an extra move and a half based on L5C taking slightly less than CMLL).

 

[PapaSmurf]

I really like the idea of mixing in L5C with Roux. The method I use for L7E in the latest LMCF still isn't optimal, and so I was thinking about L7E skips and I think there is an option to force L7E skips without 3,000 algorithms.

Carry on... (although I think we should look at L7E in general)

Consider this modification to Z-cell:

It isn't a modification to Z-CELL, it's a modification to Roux with L5C, but anyway.

1. When generating the 614 L5C algorithms, choose variants where the FR edge is dislocated/disrupted; this should not add any moves to the average since in almost every case the FR edge will be disrupted
2. For each of the 614 L5C algorithms, memorize the effect that it has on the FR edge; more specifically, memorize the starting location of the edge which ends up in the FR slot after the L5C algorithm (location + orientation)
3. Now solve first block, and back right corner.
4. We are now at the L5C step. Having looked ahead during solving of the back right 2x2 block, you know where the FR-destined edge is (in one of 7 possible locations); now use M/U moves to place that edge in the correct location such that it gets automatically solved by the L5C algorithm. According to my calculations the average number of moves this will take is about 4, with no case taking more than 5; however there is a 1 in 7 chance the FR edge is already in the FR slot which is a case we cannot easily resolve without learning another 614 algorithms
5. Do the L5C algorithm; now in 6 of 7 cases, you skip the FR edge
6. Finish with Roux L6E-EOLR

Using this method, 6/7 (85%) of the time we skip the FR edge and go directly to L6E. 1 in 6 (14%) we need to solve the FR edge after L5C. It is of course possible to learn 3 sets of L5C algorithms to deal with that 1 in 6 chance, but probably not worth it for most people.

So using this method, almost every solve you skip the last roux slot (7.5 moves average according to PapaSmurf), and that step is 'replaced' with pre-location the FR edge into the correct location such that it is automatically solved by the L5C algorithm, and that step takes around 4 moves average, so we dropped the move count by 3.5.

For the extremist who is willing to learn 1800 algorithms, you learn 3 variants of each L5C algorithm, the two additional variants deal with the case where the FR edge is already in the FR slot and oriented, the other case is where the FR edge is already in the FR slot and disoriented. While few people would learn all 1800 algorithms, those cases are crazy awesome, because if you knew the 1800 algorithms, then if the FR edge is in the FR slot (oriented or disoriented), you now get a full last-slot skip, since you do not need to pre-locate the FR edge and it is solved by the L5C algorithm variant. So in that case, you save a full 7.5 moves over Roux (plus, possibly an extra move and a half based on L5C taking slightly less than CMLL).

With current movecounts that gives 7+7+10.75 (ish)+4+12(ish)=40.75 which is very very good. If you go the other route and get a movecount of 15 or less for L7E then you have 7+7+10.75 (ish)+15=39.75 which is revelutionary tbh.

 

[CubeBlazer]

Instead of just making the final steps DFDB L5C L5E, you could have a variant like Zipper-b with a EODFB, then finish with Zipper-b LSLL. Not sure if it's any more optimal though.

 

[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