The New Method / Substep / Concept Idea Thread

[SM cubing]

This is a message to everyone interested in making a method or who is about to post a method: Stop making RouxFOP

THIS IS VERY IMPORTANT!!!!!!

 

[WoowyBaby]

I'd like to propose a new method challenge:

Create the worst method you can think of! I'll be really interested to see what you guys make up!

But, I do need to set some basic rules so the methods aren't infinite or impossible:
- If you end up breaking progress of previous steps you must restore it in the same step that you break it.
- Maximum of 12 steps are allowed(sorry about your crazy ideas w/ 100 steps).

"Score" is judged by the average (stepwise optimal) movecount.
Good luck!!

 

[White KB]

I'd like to propose a new method challenge:

Create the worst method you can think of! I'll be really interested to see what you guys make up!

But, I do need to set some basic rules so the methods aren't infinite or impossible:
- If you end up breaking progress of previous steps you must restore it in the same step that you break it.
- No more than 12 steps are allowed(sorry about your crazy ideas w/ 100 steps).

"Score" is judged by the average (stepwise optimal) movecount.
Good luck!!

A very inefficient method for big cubes (not sure if you could accurately determine average move count, but it would be very inefficient):
LBL (based on a tutorial I actually saw once)
1: Solve the yellow center (pfft, who needs to be CN, even if you have an easy white face) one piece at a time, just using the slice turn Niklas every time.
2: Pair one yellow edge at a time, one piece at a time, where the unsolved edge is on the left, the piece you need is on the right, and x represents the number of layers you have to turn to match it: xU L' U L xU'.
3: Once you have done that, place the edges in their respective places (in odd-layered cubes, use centers to determine that, in even-numbered cubes, remember the color scheme).
4: form 2nd layer for centers (somehow)
5: insert proper edges into the second layer, breaking an edge or two if necessary (e.g. blue-orange being paired with blue-red)
6: form 3rd layer centers (somehow) but it's a little bit easier.
7: pair necessary pieces to their respective edges.
8: After this it depends on the N in NxNxN, but for 4x4, skip to step 9, and for 5x5 and up, pretty much keep repeating steps 6 and 7, except with the proper layer, until everything except the last layer edges and corners are done, and replace corners when necessary.
9: pair last layer edges by displacing the two front-middle edges, then pairing ALL the white edges, then replacing those F2L pairs.
10: for 5x5, 7x7, 9x9, 11x11, etc. just solve the last layer with beginner's method (orient edges, permute edges, permute corners, orient corners), then once you're done, skip to 'step "12"'
11: for even-numbered 'N's, pretty much do step 10, but for PLL parity do r2 U2 r2 Uw2 r2 u2, where a lowercase letter represents a slice turn, and for OLL parity (this is the least efficient algorithm I know) do r2 B2 U2 l U2 r' U2 r U2 F2 r F2 l' B2 r2. then just solve with beginner's method for everything else.
"12" (not really a step). You're done! Yay...

 

[Lpell]

I'd like to propose a new method challenge:

Create the worst method you can think of! I'll be really interested to see what you guys make up!

But, I do need to set some basic rules so the methods aren't infinite or impossible:
- If you end up breaking progress of previous steps you must restore it in the same step that you break it.
- Maximum of 12 steps are allowed(sorry about your crazy ideas w/ 100 steps).

"Score" is judged by the average (stepwise optimal) movecount.
Good luck!!

1.Orient white corners on bottom(5 moves)
2.Orient white edges on bottom(6 moves)
3.Permute bottom layer(10 moves)
4.Use Salvia algorithms for the E layer(15 moves)
5.Orient U corners(7-10 moves)
6.Orient U edges(7-10 moves)
7.Use M' U2 M to solve edges(15 moves)
8.Use A(b) perm turning U layer randomly to solve corners(10-15 moves)
Total:around 78 moves

 

[PapaSmurf]

1. Permute all the D layer corners however you please, centres don't have to be solved.
2. Permute the U layer corners. Same again with centres.
3. Solve the centres.
4. Permute the D layer edges.
5. Permute the E slice edges.
6. Permute the U layer edges.
7. Twist the D corners so that they are ready for a supertwist, with algs that preserve edge permutation.
8. Same as step 7 but for U corners.
9. Flip all the D edges with algs that preserve corner permutation.
10. Step 9 but for E edges.
11. Step 10 but for U edges.
12. Perform a supertwist then a super flip to solve the cube. Alternatively, you could do a superflip them a supertwist.

 

[efattah]

The worst method isn't a fake method, it's a real method, and it's the method I used to solve the 3x3 in 1981 without any algorithms when I was 6 years old:
1. Solve the top corners
2. Solve the top edges
3. In an effort to solve the bottom corners with no algorithms, break off one of the top corners and put it back in a different way
4. Check that the bottom corners are solved; if not, repeat step 3 slightly differently
< now bottom corners are solved >
5. Rotate Z/Z' so the bottom corners are now on the R-face and solve R-edges with keyhole
6. Permute m-slices edges
7. Now m-slice edges are solved but disoriented. Since we don't know any algorithms, we need to get a skip on M-slice orientation. Break off a pair of edges UL+UR and re-solve them in a different way.
8. Permute m-slices edges
9. M-slice edge orientation skip (keep going back to step 7 if m-slice edges are not oriented)

This method has an average movecount probably around 1350 or so. There are 42 possible cases for the bottom corners and trying to solve them at random with step 3+4 takes around an hour at slow TPS, requiring around 150 iterations since you will accidentally repeat the same sequence many times. 150 iterations x around 8 moves = 1200 moves plus the rest of the solve including 100 moves for the M-slice orientation skip step, around 1350 moves.

 

[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).