# CFOP-Breaker? Mehta method

#### trangium

##### Member
Now that the method's steps are set in stone, I'm going to compare this to Roux.
FB = FB, obviously
SB ~ 3/4-Belt+EOLE. My reasoning is that both have a movecount of 12-13, <RUMr> is more ergonomic than <RUuEF>, but EOLE is algorithmic so has higher TPS and lookahead is slightly easier in 3/4-Belt.
CMLL ~ 6CP. Although 6CP's movecount is 1 less than CMLL (10 vs 11) on average, the algs for 6CP are less ergonomic because of the R2s and the algset being less developed. If/when 6CP algs get more developed, the average movecount will increase.
LSE's EO step > 6CO. 6CO takes 8.5 moves on average, whereas LSE EO often only takes 3-5 moves (if there are 4 bad edges) and never takes more than 9 moves (if there are 6 bad edges). 6CO TPS is higher, but that doesn't make up for the much higher movecount.
Rest of LSE < L5EP. L5EP is algorithmic and has one fewer edge to solve, so the movecount is lower.

Conclusion: Mehta and Roux are about equally good, but Mehta has many more algorithms than Roux, and Mehta is less developed.

#### mukerflap

##### Member
Now that the method's steps are set in stone, I'm going to compare this to Roux.
FB = FB, obviously
SB ~ 3/4-Belt+EOLE. My reasoning is that both have a movecount of 12-13, <RUMr> is more ergonomic than <RUuEF>, but EOLE is algorithmic so has higher TPS and lookahead is slightly easier in 3/4-Belt.
CMLL ~ 6CP. Although 6CP's movecount is 1 less than CMLL (10 vs 11) on average, the algs for 6CP are less ergonomic because of the R2s and the algset being less developed. If/when 6CP algs get more developed, the average movecount will increase.
LSE's EO step > 6CO. 6CO takes 8.5 moves on average, whereas LSE EO often only takes 3-5 moves (if there are 4 bad edges) and never takes more than 9 moves (if there are 6 bad edges). 6CO TPS is higher, but that doesn't make up for the much higher movecount.
Rest of LSE < L5EP. L5EP is algorithmic and has one fewer edge to solve, so the movecount is lower.

Conclusion: Mehta and Roux are about equally good, but Mehta has many more algorithms than Roux, and Mehta is less developed.
the FBs arent equal because the ergonomics are different
SB last pair is pretty much algorithmic
also replace eo with eolr

#### zzcuberman

##### Member
the FBs arent equal because the ergonomics are different
SB last pair is pretty much algorithmic
also replace eo with eolr
how arent they equal if its the first step?

#### ObscureCuber

##### Member
If you make this changes, isnt it just Like PetrusHK?
or The First version of tripod?

#### efattah

##### Member
With Mehta you solve FB in a different location than in Roux, so there's different ergonomics.
Has anyone considered solving the first block in the same place as Roux, such that the next step(s) involved solving the DF/BD edges and FR/BR edges? I'm curious as to the pros/cons of this variation.

#### Owen Morrison

##### Member
So I was thinking of some possible methods that would be similar to Mehta, and I came up with this Roux-Mehta hybrid:
Solve a Roux block on the left
Solve the FR, DR, and BR edges.
6CO
6CP
LSE

Does this seem like it would be any good?

#### Devagio

##### Member
Now that the method's steps are set in stone, I'm going to compare this to Roux.
FB = FB, obviously
SB ~ 3/4-Belt+EOLE. My reasoning is that both have a movecount of 12-13, <RUMr> is more ergonomic than <RUuEF>, but EOLE is algorithmic so has higher TPS and lookahead is slightly easier in 3/4-Belt.
CMLL ~ 6CP. Although 6CP's movecount is 1 less than CMLL (10 vs 11) on average, the algs for 6CP are less ergonomic because of the R2s and the algset being less developed. If/when 6CP algs get more developed, the average movecount will increase.
LSE's EO step > 6CO. 6CO takes 8.5 moves on average, whereas LSE EO often only takes 3-5 moves (if there are 4 bad edges) and never takes more than 9 moves (if there are 6 bad edges). 6CO TPS is higher, but that doesn't make up for the much higher movecount.
Rest of LSE < L5EP. L5EP is algorithmic and has one fewer edge to solve, so the movecount is lower.

Conclusion: Mehta and Roux are about equally good, but Mehta has many more algorithms than Roux, and Mehta is less developed.
Probably this comparison isn't enough because it doesn't take into account case recognition time for both methods, alg/execution recall, etc. The conclusion does seem roughly reliable, but I wouldn't place my bets on it. The only way to know would be to develop this method and see if the results overtake Roux results.
Has anyone considered solving the first block in the same place as Roux, such that the next step(s) involved solving the DF/BD edges and FR/BR edges? I'm curious as to the pros/cons of this variation.
I did, in fact that is how I proposed it on the new method thread. This, followed by either solving the belt and rotating, or solving it the way you say, are two options. Doing it the way you say takes away a lot of the flexibility from the method though, since you need to solve specific pieces rather than doing what you see first. Also, a D layer that is not free will force you to rotate for L5EP (or do 2 redundant D moves). Also, regarding the other option, <RUu> is not a bad moveset on magnetic cubes as I found out while practicing, so a rotation isn't really worth it. This is why I switched to FB on bottom.
So I was thinking of some possible methods that would be similar to Mehta, and I came up with this Roux-Mehta hybrid:
Solve a Roux block on the left
Solve the FR, DR, and BR edges.
6CO
6CP
LSE

Does this seem like it would be any good?
Will have worse 6CO and 6CP algs since DR is not free. Also, SB+CMLL looks much cleaner than SBedges, 6CO, 6CP; no reason to do this.

Mehta stats:

Roux stats:

Roux stats are generally stated as in the second picture and claimed to be a sub-40 movecount method by some. However, it is not correct to write sb as a single step, nor is it correct to write lse as a single step. This is because we do not see the positions of the all the pieces at once. We look at a few pieces, solve them, then look at others, and solve them, etc. (oversimplifying here, but that's the idea).

So, just to play around, I generated stats for Mehta defined as 4 steps instead of 6, mimicking Roux.

And guess what, Mehta movecount turned out less than that of Roux.
Note that Roux FB is inbuilt to be x2y colour neutral, while no such functionality is available for custom methods; so the Mehta movecount would go down further by 0.5-1 move if such functionality were available.

At the end of the day, this does not mean anything in human terms, but just a fun stat to note.

Last edited:

#### AlphaCuber is awesome

##### Member
This is totally missing the point. Even if you average 9-10 moves with single FB ("almost" optimal, a move or two above best possible), you're still gonna have the average movecount under 50 for the full solve, even in practical speedsolves.
That’s not almost optimal though. It’s about a 30% increase in movecount from optimal. If you used this definition of almost optimal and did some “almost optimal” solves for a method with a 50 move average you would be doing 65 moves which wouldn’t get you very good times.

#### Devagio

##### Member
Talking a bit about the "theory" I talked about initially (though its just simple math).

Consider our typical 2-alg method CFOP. It has 58 OLL cases and 22 PLL cases including solved. So, we should be able to solve 58x22=1276 states of the cube using these algorithms. However, due to the possible U moves before OLL, between OLL/PLL, and after PLL; and the 6 possible last layers a CN solver can have, we can actually solve 373248 cubestates using these 58+22 cases we know.
So, we are exploiting symmetry (AUF is sort of a y axis symmetry) to do a lot of the work for us. This symmetry here solves an additional factor of 373248/1276 = 292.5 cases at the cost of doing U moves at worst.

This is an important factor since if we want to solve the cube as efficiently as possible (per alg we know), we should try to maximise this factor.

Now of course, if we have 3 algorithmic steps, we can potentially exploit more symmetries of the cube.

Again consider CFOP, except even the last pair is an algorithm. There are 42 cases for this step. The additional symmetry is there are 4 possible last slots for a cross colour. The number of cubestates with LSLL remaining is roughly 224M (~5!x5!x16x81x24/2 to the first order). This gives the symmetry factor to be 224M/42/58/22 = ~4200.

Can we do any better without changing the number of algorithmic steps or increasing the number of algorithms much? There are quite a few ways you could think of, but its no use if the recognition is bad, or the algorithms are bad. For recognition to be good, lets say we limit the number of faces on which any action is going on, to 2. Now you should be able to make an exhaustive list of all the possibilities can there are.

Consider Mehta. It has 3 steps with number of cases being 72, 48, and 17 (total 137, roughly the same as 122 of CFOP). The number of cubestates where the required pieces are remaining is roughly 6!x5!x243x24/2=251M. This gives the amount of symmetry exploited to be 251M/72/48/17= ~4300. This is not much better.

But then you bring the D layer offset. Since the previous steps do not require us to have the E slice in any particular state when solved (the 3 algs do not affect the E slice), we can have the D layer offset the way we want, we can simply mend it with a single ADF. This does not affect the recognition of the preceeding steps at all. This gives us a symmetry factor over 17k!

But what about the D offset in CFOP? It already is a thing, it is called psuedo-F2L. And so far at least, we see that the recognition of pF2L is pretty hard, so including each D-layer offset with equal likelihood (perfectly unbiased pF2L) does not seem very practical.

Of course, none of this matters till the algorithms of the method that exploits symmetry better are not much worse in recognition and execution. This is what happened with ZZ-CT.
ZZCT had 105 and 72 cases, instead of 20x4+1 and 495 cases in F2L+ZBLL. Since there was only one possible LS, the number of states for a single-line solver was 5!x5!x81/2=583200 cubestates, which gives a symmetry factor of ~77. For a single-line solver using normal ZZ, there are 2.33M cubestates, which gives a symmetry factor of ~58.
These are similar numbers, but TSLE algorithms were longer than and harder to recognise than F2L algs on average, and TTLL algorithms are arguably worse compared to ZBLL algorithms. On top of that, some may argue that not having complete freedom in pair selection during F2L hinders lookahead.
All these problems compensate of the slight increase in symmetry exploitation and halving of the algorithms, so we cannot really say for sure that ZZ-CT is better than normal ZZ (in fact in my knowledge, most argue it is worse).

On the other hand, Mehta algorithms in comparison are of similar execution speed to CFOP (8.5+10+7.5=26 moves for Mehta instead of 8+10+12=30 moves for CFOP, Mehta l5ep has M moves while F2L may have rotations, both have reasonably fingertrickable movesets, etc.) and recognition seems as good for the method.
Also, the symmetry factor is not a few percent, but over 4 times that of CFOP. Basically, more cubestates are solved using Mehta algset than CFOP algset despite having similar execution, similar recognition, and similar number of algorithms.
Why is ability to solve more cubestates good? Here, it switches cross+3 (typically 25-30 moves) with EO-ledge (~20 moves).

This was basically all of my methodology of coming up with the method and reasoning that it has potential.

#### mukerflap

##### Member
Talking a bit about the "theory" I talked about initially (though its just simple math).

Consider our typical 2-alg method CFOP. It has 58 OLL cases and 22 PLL cases including solved. So, we should be able to solve 58x22=1276 states of the cube using these algorithms. However, due to the possible U moves before OLL, between OLL/PLL, and after PLL; and the 6 possible last layers a CN solver can have, we can actually solve 373248 cubestates using these 58+22 cases we know.
So, we are exploiting symmetry (AUF is sort of a y axis symmetry) to do a lot of the work for us. This symmetry here solves an additional factor of 373248/1276 = 292.5 cases at the cost of doing U moves at worst.

This is an important factor since if we want to solve the cube as efficiently as possible (per alg we know), we should try to maximise this factor.

Now of course, if we have 3 algorithmic steps, we can potentially exploit more symmetries of the cube.

Again consider CFOP, except even the last pair is an algorithm. There are 42 cases for this step. The additional symmetry is there are 4 possible last slots for a cross colour. The number of cubestates with LSLL remaining is roughly 224M (~5!x5!x16x81x24/2 to the first order). This gives the symmetry factor to be 224M/42/58/22 = ~4200.

Can we do any better without changing the number of algorithmic steps or increasing the number of algorithms much? There are quite a few ways you could think of, but its no use if the recognition is bad, or the algorithms are bad. For recognition to be good, lets say we limit the number of faces on which any action is going on, to 2. Now you should be able to make an exhaustive list of all the possibilities can there are.

Consider Mehta. It has 3 steps with number of cases being 72, 48, and 17 (total 137, roughly the same as 122 of CFOP). The number of cubestates where the required pieces are remaining is roughly 6!x5!x243x24/2=251M. This gives the amount of symmetry exploited to be 251M/72/48/17= ~4300. This is not much better.

But then you bring the D layer offset. Since the previous steps do not require us to have the E slice in any particular state when solved (the 3 algs do not affect the E slice), we can have the D layer offset the way we want, we can simply mend it with a single ADF. This does not affect the recognition of the preceeding steps at all. This gives us a symmetry factor over 17k!

But what about the D offset in CFOP? It already is a thing, it is called psuedo-F2L. And so far at least, we see that the recognition of pF2L is pretty hard, so including each D-layer offset with equal likelihood (perfectly unbiased pF2L) does not seem very practical.

Of course, none of this matters till the algorithms of the method that exploits symmetry better are not much worse in recognition and execution. This is what happened with ZZ-CT.
ZZCT had 105 and 72 cases, instead of 20x4+1 and 495 cases in F2L+ZBLL. Since there was only one possible LS, the number of states for a single-line solver was 5!x5!x81/2=583200 cubestates, which gives a symmetry factor of ~77. For a single-line solver using normal ZZ, there are 2.33M cubestates, which gives a symmetry factor of ~58.
These are similar numbers, but TSLE algorithms were longer than and harder to recognise than F2L algs on average, and TTLL algorithms are arguably worse compared to ZBLL algorithms. On top of that, some may argue that not having complete freedom in pair selection during F2L hinders lookahead.
All these problems compensate of the slight increase in symmetry exploitation and halving of the algorithms, so we cannot really say for sure that ZZ-CT is better than normal ZZ (in fact in my knowledge, most argue it is worse).

On the other hand, Mehta algorithms in comparison are of similar execution speed to CFOP (8.5+10+7.5=26 moves for Mehta instead of 8+10+12=30 moves for CFOP, Mehta l5ep has M moves while F2L may have rotations, both have reasonably fingertrickable movesets, etc.) and recognition seems as good for the method.
Also, the symmetry factor is not a few percent, but over 4 times that of CFOP. Basically, more cubestates are solved using Mehta algset than CFOP algset despite having similar execution, similar recognition, and similar number of algorithms.
Why is ability to solve more cubestates good? Here, it switches cross+3 (typically 25-30 moves) with EO-ledge (~20 moves).

This was basically all of my methodology of coming up with the method and reasoning that it has potential.
ok record solves with it

#### Silky

##### Member
So I was thinking of some possible methods that would be similar to Mehta, and I came up with this Roux-Mehta hybrid:
Solve a Roux block on the left
Solve the FR, DR, and BR edges.
6CO
6CP
LSE

Does this seem like it would be any good?
So I purposed a method back in June, before this thread came out, very similar to this method/variant called SOUP. Sorry if this is an unnecessary plug but it seemed relevant. I had no idea how to generate algs at the time ( and still don't ) so its really cool to see 6CO and 6CP being developed. Proposal below =>

So, this is a proposal for a new variant/hybrid of Roux. It is a mix of the SOAP method for 2x2 (https://www.cubestuff.cf/?soap) and Roux.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Overview/steps:

Step 1: FB + E-slice

1(a) = > This is the same step as in Roux. Blockbuild a 1x2x3 block on the L face.
1(b) = > Finish the E-slice, placing FR and BR edges in their respective spots.

Step 2: SOAP

2(a) = > Pair two D face corners (white corners) and place them in the FRU and BRU or FRD and BRD positions. These corners do no need to be oriented or permuted correctly relative to the FR and BR edges.
2(b) = > Perform SOAP style corners. First orient all 6 remaining corners and then permute them. This step would require that first block and E-slice edges are preserved.

Step 3: EO + FD edge

3(a) = > Perform EO regularly as in Roux.
3(b) = > Place FD edge finishing the second block.

Step 4: L6EP
= > Perform Last 6 edges as in normal Roux.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Pros:

(1) = > Step 1 can be planned out in inspection. This would most likely be easier than planning first block and 1x2x2 square in normal Roux.
(2) = > The orientation step of the SOAP Method is mostly 2-Gen which would make them finger-trickable. If the white corners are placed in the FRD and BRD positions (the separation step in SOAP) the orientation step could be done without looking at the D-face corners (unless you skip the separation step all together).
(3) = > The orientation algorithms can be done such that no corners on the D-face are dis-permuted meaning that if you predict/track how U-layer corners are permuted (during the orientation step) this step can be done in one look instead of two.
(4) = > Based on how the second block is solved it may be easier to preform NMLL (yellow corners/FD edge instead of white)
(4) = > The EO and FD placement can be done simultaneously.
(5) = > After performing EO and FD placement you can perform a Rw2 and see all M-slice edges leaving no blindspots.
(6) = > Because you solve 6 corners simultaneously as well as performing EO and FD placement at the same time, this method should be at least as, if not more, efficient than Roux.
(7) = > There aren't that many algs to learn, 56 I think.
(8) = > I'm naming it SOUP (or SOUXP; SOAP+Roux).

Cons:

(1) = > I haven't generated any algs (as I don't really know how to; although I assume you should be able to modify the existing ones with wide moves). Given that you need to preserve the first block and E-slice they may be less efficient (although hopefully the 2-gen will make up for that).
(2) = > SOAP as a 2x2 method hasn't proven to be viable (yet) and incorporating it may not be all that useful/fast.
(3) = > SOAP corners may have difficult look-ahead and may need to be two looked.
(4) = > Step (2) and Step (3) may prove to be more difficult than they're worth (Ya'll can decide that for yourselves).

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Being a Roux solver myself, I'm actually pretty excited for this method and am hopeful that it could be viable.

If anyone is interested in this method and wants to help generate algs that would be amazing ! Comments/thoughts and critiques are alway welcome.

Below is my original proposal for a SOAP-PCSM variant (my inspiration for SOUP), if anyone is interested.

#### efattah

##### Member
I realized something in the Mehta method can turn WaterRoux into an epic method. Original WaterRoux had you solve Roux-FB, then solve the DFB corner followed by L5C (also some other variants of that including fully solving DFR+DFB->CLL).
However, if you solve Roux-FB, then orient all 6 corners then permute all 6 corners, you could probably see the 6CO in the inspection. This would drastically reduce the number of algorithms in WaterRoux and put one of the algorithms into the inspection; after which you finish with classic Waterman/LMCF algorithms to solve the UL edge + 2 redges, then waterman L6E. This would be a rotationless method.

#### CuberStache

##### Member
However, if you solve Roux-FB, then orient all 6 corners then permute all 6 corners, you could probably see the 6CO in the inspection.
I'm not an expert on Roux, but I doubt that. @mukerflap has mentioned that he predicts FB + DR edge, so predicting location and orientation of one additional piece (an edge with only two orientations) rather than predicting the orientation of six additional pieces (corners with three possible orientations).

#### efattah

##### Member
Predicting the orientation of 6 corners is much easier than it seems. Consider the case where for roux-fb, your two corners are already solved and you finish the block with only slice moves. In this case the corners orientation does not need to be looked ahead, it stays the same as the start. In other cases you might use three face moves to solve roux-fb, which is not far to lookahead for the remaining corners. The reason i got excited about this variant is because looking ahead to edges is much harder in this case, but the corners lookahead is easier especially since you only care about the orientation of the corners, not the exact pieces.

#### Silky

##### Member
Predicting the orientation of 6 corners is much easier than it seems. Consider the case where for roux-fb, your two corners are already solved and you finish the block with only slice moves. In this case the corners orientation does not need to be looked ahead, it stays the same as the start. In other cases you might use three face moves to solve roux-fb, which is not far to lookahead for the remaining corners. The reason i got excited about this variant is because looking ahead to edges is much harder in this case, but the corners lookahead is easier especially since you only care about the orientation of the corners, not the exact pieces.
100%. Plus since you use 6CO => 6CP it becomes really easy to predict corner perm. My method (Souxp) handles this by paring and separating the white corners into DR which mean you'll only have opposite adjacent or adjacent adjacent for 6CP which makes it possible to execute from multiple angles. Souxp could be a go stepping stone to this variant of WaterRoux.

Edit: I'll also being switching to Souxp for OH and may transfer into this WaterRoux variant.

#### Devagio

##### Member
L5EP from back:
I learned all L5EP algs a few days back. L5EP here typically is when all U layer edges, and the DF edge are to be permuted. However, we use only the U layer edges to recognise the case, and so the fifth edge could be either in DF, or DB, and the average algorithms would be just as good. Since we have to do ADF anyway, it doesn’t matter whether we use a D or a D’ offset 6CP algs.
Initially I felt this would just add to the mental work, but it turns out it is extremely easy to do in practice. This change should allow us to improve many 6CP algs since we can either get both a D or a D’ offset. We’d basically have to drill 12 extra algs for this, though they’re simply mirrors of the algs we already know.

Personal progress with the method:
So far I’ve done only ~500 solves with the method because of my schedule. I currently average 22 seconds with it. For reference, my CFOP was sub-12.
I’ve memorised full L5EP, and beginner 6CO and 6CP. I’m improving quite quickly at these algorithmic steps as I get used to the algorithms and recognition (and basically brain-dead recalling what comes after what). My weakest points are intuitive EOLE (by far) and FB. After perfecting full L5EP from back and front, I will work on EOLE by probably simply semi-memorising the algs. This should also drastically improve my 6CO recognition since I’ll have the mental space to track some corner orientations.
I’m improving fairly quickly given the handicap of doing only 50 solves a day, so I expect I should be 17-18 seconds in a month; that’s when I’ll record solves and put them up.

#### Silky

##### Member
L5EP from back:
I learned all L5EP algs a few days back. L5EP here typically is when all U layer edges, and the DF edge are to be permuted. However, we use only the U layer edges to recognise the case, and so the fifth edge could be either in DF, or DB, and the average algorithms would be just as good. Since we have to do ADF anyway, it doesn’t matter whether we use a D or a D’ offset 6CP algs.
Initially I felt this would just add to the mental work, but it turns out it is extremely easy to do in practice. This change should allow us to improve many 6CP algs since we can either get both a D or a D’ offset. We’d basically have to drill 12 extra algs for this, though they’re simply mirrors of the algs we already know.

Personal progress with the method:
So far I’ve done only ~500 solves with the method because of my schedule. I currently average 22 seconds with it. For reference, my CFOP was sub-12.
I’ve memorised full L5EP, and beginner 6CO and 6CP. I’m improving quite quickly at these algorithmic steps as I get used to the algorithms and recognition (and basically brain-dead recalling what comes after what). My weakest points are intuitive EOLE (by far) and FB. After perfecting full L5EP from back and front, I will work on EOLE by probably simply semi-memorising the algs. This should also drastically improve my 6CO recognition since I’ll have the mental space to track some corner orientations.
I’m improving fairly quickly given the handicap of doing only 50 solves a day, so I expect I should be 17-18 seconds in a month; that’s when I’ll record solves and put them up.

#### TerryD

##### Member
When will you put the algorithms in a doc with pictures? I'm having trouble reading some of the cases.

#### Devagio

##### Member
When will you put the algorithms in a doc with pictures? I'm having trouble reading some of the cases.
Here is what I started working on today.
This is a github pages site for the method, which for getting done with ASAP I'm using the same styling and format as YruRU. I have added a few of the beginner pages, so that it is easier for people to get started.