# CFOP-Breaker? Mehta method



## Devagio (Aug 15, 2020)

EDIT: The following descriptions, simulations and algorithms of the method are obsolete now, thanks to the efforts of the community in developing the method. For a better understanding of the method, please check out https://devagio.github.io/Mehta/ or read page 5 onwards on this thread, and join the discord community if interested (invite link is available in the about section of the website and here after page 5).

*Philosophy and motivation:*
Algorithmic methods are doing fairly well compared to block building methods, and for good reason. TPS on the new hardware has shot up and it makes sense to make best use of it. A method with a bearable number of algorithms, yet highly algorithmically reliant and with good recognition has the potential to beat a good deal of methods. A means to achieve that is to have 3 algorithmic steps (compared to 2 for CFOP for example); while ensuring that those algorithms do indeed tackle a large set of cases (2LLL CFOP handles ~15k cases).
Orientation steps are almost always recognition friendly as long as they involve one (or two) top colour (like TSLE is decent for recog, OLL is pretty good, etc. but LEOR EO is hard) Permutation steps are good for recognition if a single glance at a cube, and registering 4-5 stickers at most can uniquely identify each case (like 2 sided PLL recognition system if good, ZBLL recognition on the other hand is hard, so is 4x4 PLL).
Cube symmetries can play a huge role in reducing number of algorithms while getting tons of cases solved (There are 72 PLL cases, but symmetry reduces it to 22 (21+1)). These symmetries can be exploited much better once we think about it.

Based on these primers and a bit of work, there seems to be one very promising end to a solve using 3 algorithms:
Suppose a 2x2x3 is solved on DL; and FR and BR edges are solved.
Alg-1: orients 6 corners. This will be a short <R,U> alg; and surprisingly, there are very few cases thanks to the freedom of U layer and the S slice symmetry. Also, R2 setups cut this down much further. There are 23 + (4 x 8) + (2 x 8) = 71 cases, though only 39 algorithms excluding mirrors. If we consider R2 setups, this number goes below 30.
Alg-2: Permutes 6 corners. These will be <R,U,D> algs (<R2,U,D> is enough, but algs may get lengthy); and again surprisingly, there are very few cases thanks to the same freedom and symmetry. There are 5 + (4 x 6) + 18 = 47 cases, though only 29 algorithms excluding mirrors. 2 sided recognition is possible here.
Alg-3: L5E, <M,U> gen, very simple to recognise during the previous alg; though almost 200 cases (60-70 algs excluding mirrors and inverses)

This 3-alg-system, which without any reduction has around 300 algs can reduce the cube state from a possible 6! * 5! * 3^5 * 2^3 = 168M cases! Although, it is possible to influence L5E during belt by doing partial EO (6CO and 6CP doesn't influence EO).
For comparison, CFOP LSLL is a 3-alg-system with 119 algs with 9M cases.
The algorithm quality (length, movesets, recognition and look-ahead ability) is at worst comparable to CFOP LSLL.


*Now to the hard part:*
How do we achieve " a 2x2x3 is solved on DL; and FR and BR edges are solved"?

Two premises about this.
Firstly, blockbuilding is probably the best thing that can be done with the inspection time in terms of reducing the number of cubestates. A roux block does this slightly better than a petrus block, which is better than a cross; all solving the same number of pieces (counting centres, since roux centres aren't fixed).
Second, there is a reason CFOP is as successful as it is, and that is the symmetry in F2L. We can choose to do whichever F2L pair we please, and we can do these in any order. This is very good for a step that is neither algorithmic, nor block building; because we can simply do whatever we see first. Finally, we can use only the last pair to influence LL.

This gives us a beautiful way to achieve the above mentioned cubestate. A roux block can be done in inspection on bottom, and then each of the 4 edges FR, BR, BL, FL can be placed between corresponding centres in any order convenient; while influencing EO if one wants to reduce the L5E set. And you have your required cubestate! The best part is, this central "belt" doesn't have to align with FB, because at the end of the solve, we can do an AUF with an ADF and will be done.


*Summing it all up:*

Step 1: FB (~6 moves)
Step 2: Belt (~9 moves) <R,U,u>
Step 3: 6COLL (~13 moves) <R,U>
Step 4: 6CPLL (~12 moves) <R,U,D>
Step 5: L5E (~15 moves) <M,U>
Avg ~ 55 moves

Promises a higher TPS than CFOP, since FB and cross should be at worst similar TPS, belt is higher TPS than F2L since you don’t have to track 2 pieces or rotate, and a higher percentage of the solve is algorithms; which in all makes a higher TPS objectively certain.

The symmetry exploitation keeps the method as efficient as CFOP despite being much more algorithmic.




*Examples:*

Scramble: B L' U F' L' R2 D' B F' U B U' L R2 U2 F2 B2 L' D2 U2 F' B R2 L B

y2 // inspection
F U2 B' L F B2 // FB (6/6)
u R u R' u R2 u' R' U2 R // Belt (10/16)
U R' U' R U2 R' U' R // 6CO (8/24)
R2 U2 R2 U'D' R2 U R2 U' R2 D R2 D' // 6CP (13/37)
M' U M U2 M' U M' U M2 U' M' U2 M' U2 M2 // L5E (15/52)
U'D' // Adjusting faces (2/54)
(50 ETM)


Scramble: U L' B' R2 U2 L2 U B' D2 R B2 L F2 R' F2 D2 F2 R2 F2 D

x2 // inspection
B L' F U' B2 R B' // FB (7/7)
U R u' R u2 R2 u' R' U R // Belt (10/17)
R' U' R2 U' R' U R2 U R // 6CO (9/26)
D' R2 D R2 U' R2 U2D' R2 U' R2 U' R2 // 6CP (13/39)
U2 M' U' M U' M' U M2 U2 M U M' U2 M' // L5E (14/53)
(47 ETM)



Through this thread, I hope to improve upon this idea and generate 6CO, 6CP and L5E algs (and perhaps a better recognition system if there is one). Constructive criticism is more than welcome. If you intend to, please let me know if you would be willing to assist me in generating the algorithms. Most importantly, let it be known if you're willing to give this method a try and attempt to beat your CFOP global with it.
I will soon be making a github (similar to YruRU) where I will put all the algs and relevant development discussed on this thread and elsewhere.

Disclaimer: The title isn't meant to offend. It is both a milestone setter, and a hilarious continuation of the theme started in YruRU.


*EDIT (19 August):*

The method has evolved quite a bit thanks to the efforts of numerous people on this forum and otherwise.
Here is the improved version of the method, with move statistics for non-CN solvers:

Step 1: First block (~7 moves) [There are 24 possibilities for a fully CN solver]
Step 2: 3-quarters belt (~7 moves) [There are 4 possible 3QB for each FB, and 6 piece solving orders for each 3QB]
Step 3: Edge orientation+Last edge (~6 moves) [55 cases]
Step 4: 6-Corners' Orientation (~8.5 moves) [71 cases]
Step 5: 6-Corners' Permutation (~10 moves) [47 cases]
Step 6: Last 5 edges' Permutation (~7.5 moves) [16 cases]
Step 0: Various face adjustments (~4 moves) [Between algorithms]

Average move-count: ~50
Total algorithm count: 134 (+55 intuitive)



Spoiler: All Algorithms






Spoiler: EOLE algs




GGGGGGR U' R'GGBBU F R F' U2 R'U R' F R2 F' U2 R'GBGBU2 F R F' U R'U2 R' F R2 F' U R'GBBGU' R U2 R2 F R F'U F R' F' R2 U2 R'BGGBU R F' U2 F R'BGBGR2 U' F R F' R2BBGGU2 F R' F' R2 U R'BBBBU S' U S R U2 R'U R' F R2 F2 U2 F R'avg5.25GBGGGBU2 R F' U F R'GGBGU' R U R2 F R F'GBGGF' U2 F R U' R'BGGGU' R' F R F'GBBBU2 F R F2 U' F U2 R'BGBBU F R F2 U2 F R'BBGBU2 R' F R2 F2 U F R'U2 R F' U F2 R2 F' RBBBGU S' U' S U2 R' F R F'avg6.125BGGGGBF R F' R'GGBGF R' F' RGBGGR U R' F' U' FF U R' U' F' U RBGGGU' F R' F' R2 U' R'GBBBU2 R F' U2 F2 R' F'BGBBU' S' U S R U R'U R U2 F' U F2 R' F'BBGBU' R' F R2 F2 U' F R'U2 S' U' S U R U' R'BBBGU S' U S U' F R' F' Ravg5.875BBGGGGU' F' U FE R' U' RGGBBF' U F2 R F' R'U R F R' F2 U' FGBGBU2 R F R' F2 U2 FF R F2 U2 F U2 R'GBBGU R' F R F2 U' FF R' F2 U2 F U2 RBGGBu' F R F'BGBGF R' F2 U' F U Ru' F U R2 U' R F'BBGGF' U2 F2 R' F' RU2 R' F R F2 U2 FBBBBU S' U S u' R' U' Ravg5.625solved0Bnil1BR' F R2 F' R'2B (adj)R F R2 F' RF U R U' R' F'2B (opp)F R U R' U' F'3BS' U SF R F' U2 F R' F'4BR2 S' U S U2 R2avg4.17flipped0BF R F2 U F U2 R'R U R' F R F' R'1BF' U2 F R U R'R U R' F R' F' R2B (adj)F R F2 U' F R'2B (opp)R F' U F2 R' F'3BR' F R F' U' R' F R F'4BS' U S R U2 R' F' U' Favg7.17G0BR' U' R U R1BR F R' F'R U F R' F'2B (adj)R2 F R F' R2R U' F R' F'2B (opp)R F U R' U' F'3BF R' F2 U2 F R U2 R4BF R' F' R2 U2 F R' F'avg6.00B0BF u' R u F21BF R F' U' R'2B (adj)u' F R' F'2B (opp)u' F U R' U' F'F R F2 U2 F U' R'3BR F' U' F2 R2 F' R4Bu' F R' F' U2 R F R2 F' Ravg6.17

The 56 cases are divided into 8 subsets (8x4 + 6x4). The first four are when the last edge is in UF and the slot is in FR. The subsets are denoted by the orientation of the last edge (in UF) and the edge in FR respectively. Each case in these sets is denoted by the orientation of UL, UB, UR and DR edges respectively. The next two cases are when the last edge is in FR itself, either solved or flipped. The final two cases are when the last edge is in DR.

Note that all the algorithms are entirely intuitive, and should be treated so when beginning. The overall average movecount of these inserts is 5.80 moves.





Spoiler: 6CO algs




DDHR' U2 R U2 R U2 R U2 R'R' U' R2 U' R U2 R2 U' R'PiR U2 R2 U' R2 U' R2 U2 RSuneR U R2 U' R2 U RAntisuneR U2 R' U' R U' R'UF U' R2 U R2 U F'D R D' R2 U R2 D R' D'TR D' R U2 R' D R'R U R D R' U' R D' R2LR D' R U' R' D R'Onilavg6.63RRHR U' R' U2 R' U' R U2 R U' RPiR U' R' U' R U' R U2 R' U R'SuneR U' R' D' U' R U2 R' DAntisuneR' U R D U R' U2 R D'UR U' R2 U' R U2 R2 U' RTR U2 R' U' R2 U2 R' U R'R U R U2 R2 U' R U2 R'LR U R U2 R' U R'OD' R U' R' D R' U R2 U' RR U R U' R' U R U' R' U R'avg9.13FBHR U R' U' R2 U R2 U' R2 U2 R' U' R'R' U' R U R2 U' R2 U R2 U2 R U RPiR U R2 U2 R2 U R' U2 R' U' RSuneD' R U' R' D U' R U2 R'R2 U R' U2 R U' R2 U R U2 R'AntisuneD R' U R D' U R' U2 RR2 U' R U2 R' U R2 U' R' U2 RUR' U2 R2 U' R2 U' R2 U2 R'TR U2 R U2 R U2 R U2 RLR' U R U R2 U' R2 U R' U2 ROR2 U' R D' R U2 R' D RR U2 R U' R' U2 R U' R' U2 R'avg9.75RDhandL' U R2 U' R2 LR' D' R U' R' D RasiaR U' R' U' R U2 R'SD R' U2 R U' R' U' R D'pR' U R U2 R2 U' R U2 RdogR U' R' U2 R U' R'hammerB' R2 U' R2 U BR D U' R' U2 R D' U' R'clockR' U2 R' U R2 U' R' U2 ReagleR' U2 R U R2 U' R U2 Ravg7.75FDlegR D' R U R' D R'americaD R' U R U R' U2 R D'R2 U' R U2 R' U' R U' RNR U2 R' U R U R'bR S' U2 S RR U R' U2 R U R'catD R' U R U2 R' U R D'R' U' R2 U2 R' U R2 U2 R2 U' R'sickleB' U' R2 U R2 BR2 U R' U R U2 R' U R'fanR U' R' U' R U' R' U R U2 R'pigeonR U2 R' U R U' R' U' R U' R'avg8.13DRlegL U' R2 U R2 L'R D R' U' R D' R'americaR' U R U R' U2 RND' R U2 R' U R U R' DbR U' R' U2 R2 U R' U2 R'D' R U R' U2 R U R' DcatR' U R U2 R' U RsickleF R2 U R2 U' F'fanR U2 R U' R2 U R U2 R'pigeonR U2 R' U' R2 U R' U2 R'avg7.75DBhandR' D R' U' R D' RasiaR2 U2 R' U R' U R U2 R'SR' U2 R U' R' U' RpR' S' U2 S R'R' U' R U2 R' U' RdogD' R U' R' U2 R U' R' DR' U R U R' U' R U R' U2 RhammerF U R2 U' R2 F'clockR' U R U R' U R U' R' U2 ReagleR' U2 R U R' U' R U' R' U' Ravg8.13FRhandR U' R U' R' U2 R'asiaR U2 R U' R2 U2 R U R'SR U' R' U2 R' U R U' R2 U' R'pR U' R2 U R' U R' U2 RR U2 R' D' U R U R' DdogR U R U R' U R U' R' U2 R'hammerR U2 R' U R' U R2 U' RR U2 R' U R2 U' R' U2 R'clockR' U R U' R U' R U R'R U R U R2 U R U R'eagleR U2 R' U R2 U2 R2 U2 R U R'avg9.5RBlegR' U R' U R U2 RamericaR2 U' R' U R U2 R' U R'NR' U R U2 R U' R' U R2 U RR' U' R U' R' U' R2 U' R2 U R'bD' R U' R' D U2 R U' R'D R' U2 R D' U' R' U' RcatR' U' R U R2 U' R2 U R' U' RsickleR U2 R U R2 U' R U2 R'R' U2 R U' R2 U R U2 RfanR U' R' U R' U R' U' RpigeonR' U2 R U' R2 U2 R2 U2 R' U' Ravg9.5
The 72 cases (71+1) are divided into 9 subsets, depending on the orientations of DFR and DBR corners. For example, the subsection "RB" is when the DFR corner is oriented towards R and the DBR corner is oriented towards B.

In 3 of the subsections, there are familiar OCLL patterns like T, U, L, O, H, Pi, etc. The other 6 subsets (3+3) have different patterns which I have tried to name based on how they look. Note that there is a symmetry here. For instance, The mirror image of "dog" in one of the subsets is "cat" in the other subset; because dog and cat are similar words. Other such pairs are hand-leg, pigeon-eagle, sickle-hammer, etc. This will become obvious with time.

Under every subset, the average movelength of the main algs is mentioned. The overall average movelength of all of these algorithms is 8.47 STM. There are shorter algorithms for some of these cases, however I have tried to pick the fastest ones. It is interesting to note that in the 5 subsets (40/72 cases) where there is at least one of the D corners oriented, the average alg length is on average 20% less than the remaining 4, so an advanced solver may try to force at least one of the D corners to be oriented for better cases.





Spoiler: 6CP algs



These algorithms were generated and compiled by @trangium

DF Loc.DB Loc.CaseAUFAlgAUFAlt AlgAUFAlt Alg56SolvedD'AdjacentR U R' F' R U R' U' R' F R2 U' R' D'DiagonalR U' R' U R U' D' R2 U R D R U' D' R2F R U' R' U' R U R' F' R U R' U' R' F R F' D'65SolvedF R U R U' R' F' R U' R U R2 U' R D'R' U R' F' R U R' U' R' F R2 U' R' U' R2 D'AdjacentR U R' D' R U' D2 R' U' R D2 R'R2 U R2 U2 R2 D' R2 U R2 U' R2DiagonalR U' R' U R' U2 R2 U R U R' U' R2 D'26Front OppR2 U2 R2 U' R2 U' R2 D'U2R2 U R2 U R2 U2 R2 D'Right OppU'D R2 U2 R2 U R2 U R2 D2UD R2 U' R2 U' R2 U2 R2 D2Double OppU2x R' U R U' R' U R U' R' U R U' F' x'R' D R U' R D' R' U2 R D R' U R' D' R D'R2 U R2 D R2 D' R2 U' R2 D R2 D2Front BarD' R2 U R2 U' R2 D R2 D'D' R U R' U R2 D R D' RRight BarUR2 D' R2 U R2 U' R2UD' R' D R' D' R2 U R U' R'Double BarR2 U R2 U' R2 D R2 U' R2 U R2 D2R2 U R2 F R U R U' R' F' R U2 R' U2 R' D'62Front OppR2 U2 F U F' R2 F U' F' D'R2 U' R2 D R2 U' R2 U R2 D' R2 D'Right OppU'R' F' R U R2 U' R' F R U' R2 D'Double OppU2R2 U' D R2 U' R2 U R2 D2U2R2 F2 U' F2 D R2 D2Front BarU'R2 U' R2 D'Right BarR2 U' R2 U' R2 D R2 U' R2 U R2 D2U2R' U2 R D R D' R D R U2 R D2U'D' R U R' U' R U2 R D R' U2 R2 D' RDouble BarU'x R' D' R U2 R' D R U2 F' x'R U2 R2 U R D R' U' R D2 R U2 R'U2R2 U' R2 D' R2 U R2 U R2 U2 R252Front OppD' R2 U2 R2 U' R2 U' R2U2D' R2 U R2 U R2 U2 R2 U2Right OppU'R2 U2 R2 U R2 U R2 D'UR2 U' R2 U' R2 U2 R2 D'Double OppU2D' x R' U R U' R' U R U' R' U R U' x'U'R D' R' U R' D R U2 R' D' R U' R D R' D'U'R2 U' R2 D' R2 D R2 U R2 D' R2Front BarU2R2 D R2 U' R2 U R2 D2U2D R D' R D R2 U' R' U R D2Right BarU'D R2 U' R2 U R2 D' R2 D'U'D R' U' R U R2 D' R' D R' D2Double BarU'R2 U' R2 U R2 D' R2 U R2 U' R2R U' R U' R' U R' U R' F' U R' U' R F D'25Front OppU2R U R2 U R' D R' U' R D2 R U' R'U'R2 U R2 D' R2 D R2 U R2 D' R2Right OppU'R2 U F U F' R2 F U' F' D'R D' R' D R' U D' R2 U' R D R' D' R2Double OppUR2 U D' R2 U R2 U' R2UR2 B2 U B2 D' R2Front BarUR U2 R' D' R' D R' D' R' U2 R'U'R2 U R2 U R2 D' R2 U R2 U' R2Right BarR2 U R2 D'Double Barx R D R' U2 R D' R' U2 B' x'R U R' U R U' R' D' R U R' U' R U' R'231=2, 3 AdjU'R2 U2 R2 D'1=2, 3 OppR2 U' R2 U2 R2 U' D' R2 U R2 U' R2D' R U R2 D R' D' R U2 R2 U R2 U R2=3, 1 AdjU'R F' R2 F R U R' F' R2 F R U R2 D'D R2 U' R2 U R2 D' R2 U' R2 U2 R2 D'R' U' R F' R2 F U R' F' R' F U R2 D'2=3, 1 OppR2 U R2 U R2 D R2 U' R2 U R2U'R2 U R U' R U R' U R2 U D' R U' R'R D' R U R' D R' U' R' D R' U R D' R D'All diff, 1 and 2 oppD' R U' R' U2 D R2 U2 R2 D' R U R'UF U R U' R' F' R2 F R U R' U' F' R2 D'All diff, 2 and 3 oppU2R2 U R2 U' R2 U' D' R2 U R2 U' R2U2D' R' D R2 U R U2 R' U' R2 D' R' U' R2321=2, 3 AdjU2D' R U' R U R' D R D' R' U R2 U2 R21=2, 3 OppU2D' R2 U R2 U D R2 U2 D' R2U2D' R2 U R' U D R2 U' D' R U' R2F' U R' U' R U R' U' R U R' U' R F D'2=3, 1 AdjR2 U2 D' R2 U R2 U' R22=3, 1 OppF2 D' r2 D r U' r F2 r' U rUR2 U R2 U' R2 U2 D' R2 U R2 U' R2All diff, 1 and 2 oppR2 U R2 U' R2 U R2 D'U2R2 U' R2 U R2 U' R2 D'All diff, 2 and 3 oppD' R2 U R2 D R2 U' D' R2131=2, 3 AdjR2 U R2 U' R2 U2 R2 D'R2 U' R2 U2 R2 U' R2 D'1=2, 3 OppUR2 U D R2 U' R2 U R2 D22=3, 1 AdjU2R2 U' R2 D' R2 D R2 U' R2 D' R2U2R2 U' R' D' R D R2 U' R' U R' U' D' R2U'R U' R F2 R' U R' U' R2 F2 U2 R2 D'2=3, 1 OppUR2 U R2 D' R2 U R2 U R2 U2 R2All diff, 1 and 2 oppUR D R' D' R2 U R D R2 U' D' R D'U2R U' R F' R2 F U R' F' R' F D'x R2 U R' U' R U R' U' R U R' U' R' F' x'All diff, 2 and 3 oppU2R2 U' D' R2 U R2 U' R2
DF and DB location numbers follow the YruRU numbering scheme.
For the bottom cases, the Case column refers to 3 stickers on the right. For the two cases above that, the case numbers refer to 3 stickers on the front








Spoiler: Beginners' version



*Step 1:* Make a 1x2x3 in DL (i.e. solve DL, DF, DB edges and DFL, DBL corners. E slice centres are not necessarily solved). If this is hard, make a 1x2x2 in DLF or DLB during inspectiom, and then extend it with a pair. I suggest to try and be at least partially color neutral here. Roux FB tutorials should certainly help.

*Step 2:* Intuitively solve 3 belt edges using <R, U, u> moveset. <F, f> moves are okay too. Remember, you do not need to insert edges with triggers since the R layer is free. Whenever possible, try and solve 2 edges at once, this should become natural with practice.

*Step 3:* Solve the last belt edge while intuitively doing EO. CFOP edge control tutorials should help. Some useful triggers to start with are F<U>F', R'FRF', S'US, R2UR2, etc. Keep this intuitive for now, you can then start to slowly optimise your solutions using the EOLE algorithms.

*Step 4a:* If only 0 or 1 of the 6 remaining corners are oriented (you’ll skip this 66% of the time), use either Sune or Antisune to ensure at least 2 of the 6 corners are oriented.

*Step 4b:* Use an R2<U>R2 trigger to put two of the oriented corners in DFR and DBR.

*Step 4c:* You now have 7 possible cases for CO, use an alg.

*Step 5a:* Use an R2<U>R2 trigger to solve the DBR corner.

*Step 5b:* You now have 8 possible cases for CP, use an alg.

*Step 6a:* Insert the D edge to the bottom layer using M'U2M.

*Step 6b:* You now have 4 possible EP cases, use an alg.




Spoiler: Beginner CO algs (step 4c) 




HR' U2 R U2 R U2 R U2 R'R' U' R2 U' R U2 R2 U' R'PiR U2 R2 U' R2 U' R2 U2 RSuneR U R2 U' R2 U RAntisuneR U2 R' U' R U' R'UF U' R2 U R2 U F'D R D' R2 U R2 D R' D'TR D' R U2 R' D R'R U R D R' U' R D' R2LR D' R U' R' D R'
Or use regular OCLL algs.





Spoiler: Beginner CP algs (step 5b)




Location of DFR cornerCaseMain algAlt algDFRsolvedD'DFRopposite on rightR U R' F' R U R' U' R' F R2 U' R' D'DFRdiagonalR U' R' U R U' D' R2 U R D R U' D' R2F R U' R' U' R U R' F' R U R' U' R' F R F' D'UBLopposite in frontR2 U2 R2 U' R2 U' R2 D'U2 R2 U R2 U R2 U2 R2 D'UBLopposite on rightU'D R2 U2 R2 U R2 U R2 D2UD R2 U' R2 U' R2 U2 R2 D2UBLdiagonalU2 x' R' U R U' R' U R U' R' U R U' F' xR' D R U' R D' R' U2 R D R' U R' D' R D'UBLheadlights in frontD' R2 U R2 U' R2 D R2 D'D' R U R' U R2 D R D' RUBLheadlights on rightU R2 D' R2 U R2 U' R2UD' R' D R' D' R2 U R U' R'UBLsolvedR2 U R2 U' R2 D R2 U' R2 U R2 D2R2 U R2 F R U R U' R' F' R U2 R' U2 R' D'






Spoiler: Stats



Total number of algs: 7+8+4 = 19

Expected movecounts:
Step 3: 10 moves
Step 4: 13 moves
Step 5: 14 moves
Step 6: 13 moves

Total from step 3 to end: 40 moves
Total: 60-65 moves for a beginner
Source: HARCS





Spoiler: Beginners' Example



Scramble: R' B' F2 L2 U2 R' B2 R' B' L' B2 F' R2 U' F' D R2 B' D2 B F R F U' L

L2 D R' // 1a (making a 1x2x2)
R' U2 R D L' y' // 1b (extending to 1x2x3)
U2 R' // 2a (belt edge 1)
u2 U R // 2b (belt edge 2)
u' R // 2c (belt edge 3)
F' U F R U2 R' // 3 (intuitive EOLE)
R' U' R U' R' U2 R // 4a (orienting at least 2 corners)
R2 U2 R2 // 4b (putting in the 2 corners)
R U2 R2 U' R2 U' R2 U2 R // 4c (orienting L4C)
R2 U' R2 // 5a (permuting DBR corner)
U R2 D' R2 U R2 U' R2 // 5b (permuting other corners)
U2 M' U2 M // 6a (permuting D layer edge)
M2 U M2 U M' U2 M2 U2 M' // 6b (EPLL)

This solve had no skips. Without cancellations, movecount = 3+5+2+3+2+6+7+3+9+3+8+4+9 = 64 moves.








Spoiler: Stats Simulation











Ran a 10000 solve simulation of a constrained version of the method.

Constraints:
- only one FB instead of a possible 24 FB
- exactly the same 3 belt edges solved first instead of 4 possible combinations

And then there were the general constraints that there is no influencing of one step on the next (which is kind of the point though).

The best part is, this number actually holds for the method because there isn't much scope of inefficiency. FB is planned in inspection so any intermediate solver is going to be almost optimal, and the last 4 steps are algorithms. The only place where fluid intuition is needed is the first 3 belt edges (3 pieces).
In comparison, theoretical and practical CFOP numbers are nowhere close because of the move inefficiencies even top solvers have during F2L (8 pieces).


----------



## mukerflap (Aug 15, 2020)

i strongly doubt belt will have higher tps than F2L with that many wide U moves. I think its better to just a 223 then solve the belt edges


----------



## Username: Username: (Aug 15, 2020)

mukerflap said:


> i strongly doubt belt will have higher tps than F2L with that many wide U moves. I think its better to just a 223 then solve the belt edges


Wait a min, if a 2x2x3 and 2 belt edges are better, basically, TPS is hit by a lot, which is the purpose of the method lol


----------



## TheSlykrCubr (Aug 15, 2020)

Belt can be called ribbon. Ribbon sounds a bit like rivers. Rivers of babylon is a song. Ribbon of Babylon (ROB for short) is a funny name. Please call it the ROB method and I would be happy.

I think it would be easier if you were to create a set of short algorithms that orient and permute 2-3 each time, and repeat. It would be easier to learn, generate, and (if very short,) could be faster then 2 separate algorithm sets. As far as i know, there isn't any other (good) method that does this.


----------



## Devagio (Aug 15, 2020)

mukerflap said:


> i strongly doubt belt will have higher tps than F2L with that many wide U moves. I think its better to just a 223 then solve the belt edges


So the main aim is to set up the cube so that a 223 and the remaining 2 belt edges are solved; because 6CO, 6CP and L5E is the entire point.
I completely agree that if it is possible for someone to plan a 223 in inspection (fast people should be able to do that) then this is the way to go. 
However, I do not think TPS would drop due to below F2L TPS due to u moves, because there isn’t any need to purposely slow down for lookahead.
Even if it does slow down to F2L TPS or lower, I guess 8-9 moves of slower turning would still be as fast as 2 F2L pairs. If FB is as fast as cross, 3rd pair and LSLL will certainly be slower than 6CO, 6CP, L5E; so things should balance out for the methods to at least be comparable.

But yes; the goal for an aspiring world record holder should be to inspect a 223 and track the remaining edges in inspection. FB+belt is a way of achieving the same thing with more tricks possible; it doesn’t define the method and the choice is upto the user.


TheSlykrCubr said:


> Belt can be called ribbon. Ribbon sounds a bit like rivers. Rivers of babylon is a song. Ribbon of babylon is a funny name. Please call it this and i would be happy


Lol no. Firstly, it doesn’t matter how the FB+belt is done, the point of the method is 6CO+6CP+L5E. At the end of the day, blockbuilding FB+belt will the the supreme thing to do.
Plus, I guess I’m gonna keep the name simple this time to avoid various confusions.



TheSlykrCubr said:


> I think it would be easier if you were to create a set of short algorithms that orient and permute 2-3 each time, and repeat. It would be easier to learn, generate, and (if very short,) could be faster then 2 separate algorithm sets. As far as i know, there isn't any other (good) method that does this.


Totally disagree. Apart from horrible recognition, there will be too much decision making. Plus, there’s a little theory I built up to “derive” 6CO+6CP+L5E. I’ll post it on this thread in a while.


----------



## TheSlykrCubr (Aug 15, 2020)

Ok, I have an idea which will probably get shot down straight away, but when making the 2x2x3 block, leave out the edge parallel to the one that gets solved in L5E so that you have a lower-case n shape. Then you can do L6E, which has waaaaaay more information out there on how to get good. Also gives it a satanic vibe, which is good since it's the cfop-breaker. But it wouldn't work with your way of deriving, so it would be more work for you to get it right.

Also, wouldn't allowing wide moves in the algs make them faster to execute/ shorter in general?

If you don't like either of these ideas, i'll shut up for a while


----------



## Devagio (Aug 15, 2020)

TheSlykrCubr said:


> Ok, I have an idea which will probably get shot down straight away, but when making the 2x2x3 block, leave out the edge parallel to the one that gets solved in L5E so that you have a lower-case n shape. Then you can do L6E, which has waaaaaay more information out there on how to get good. Also gives it a satanic vibe, which is good since it's the cfop-breaker. But it wouldn't work with your way of deriving, so it would be more work for you to get it right.
> 
> Also, wouldn't allowing wide moves in the algs make them faster to execute/ shorter in general?
> 
> If you don't like either of these ideas, i'll shut up for a while


No no, keep them coming; you never know what might be ground breaking.

I did think of leaving out that edge to get L6E. The issue with that is, you never know what edge will end up in that spot. If it is a useful edge, it’ll be a big hassle removing it.
Secondly, this doesn’t give any major boost in speed, while L5E is much faster than L6E since it is one-lookable.

Wide turns do make things shorter and rotationless, but they make the cube grip awkward which slows down turning. I do not think it is a major issue here; but sometimes it may be.


----------



## Username: Username: (Aug 15, 2020)

Devagio said:


> No no, keep them coming; you never know what might be ground breaking.
> 
> I did think of leaving out that edge to get L6E. The issue with that is, you never know what edge will end up in that spot. If it is a useful edge, it’ll be a big hassle removing it.
> Secondly, this doesn’t give any major boost in speed, while L5E is much faster than L6E since it is one-lookable.


People basically do L6E so pauselessly and so fast that they basically one looked it, the way you see LSE is not several sub-steps, but rather one long step.


----------



## TheSlykrCubr (Aug 15, 2020)

Devagio said:


> No no, keep them coming; you never know what might be ground breaking.
> 
> I did think of leaving out that edge to get L6E. The issue with that is, you never know what edge will end up in that spot. If it is a useful edge, it’ll be a big hassle removing it.
> Secondly, this doesn’t give any major boost in speed, while L5E is much faster than L6E since it is one-lookable.



From Speedsolving.com's Wiki page for L5E

"The most advanced system would be to simply solve in one step. Nobody has generated the algorithms for this yet, but it may not be a good idea because of the large number of cases and bad recognition. For the worst ones the algorithm will probably just be the same as in the 2-step solution, so the benefit will be small at best."


----------



## Devagio (Aug 15, 2020)

TheSlykrCubr said:


> From Speedsolving.com's Wiki page for L5E
> 
> "The most advanced system would be to simply solve in one step. Nobody has generated the algorithms for this yet, but it may not be a good idea because of the large number of cases and bad recognition. For the worst ones the algorithm will probably just be the same as in the 2-step solution, so the benefit will be small at best."


The L5E page was made in 2008, it may have relics of cubing advice that no longer holds. The world record time is literally one third of the world record time back then. 
A major thing in cubing is, even if two solutions are same, a one-looked solution is much much better than a two-look solution because of the massive TPS people have today.
Also, EO can be influenced during belt, which will give only the great cases (i.e. ones with 0 or 4 bad edges).


----------



## mukerflap (Aug 15, 2020)

Devagio said:


> No no, keep them coming; you never know what might be ground breaking.
> 
> I did think of leaving out that edge to get L6E. The issue with that is, you never know what edge will end up in that spot. If it is a useful edge, it’ll be a big hassle removing it.
> Secondly, this doesn’t give any major boost in speed, while L5E is much faster than L6E since it is one-lookable.
> ...


yeah lse is pretty much 0 look since you predict how to do it in CMLL



Devagio said:


> So the main aim is to set up the cube so that a 223 and the remaining 2 belt edges are solved; because 6CO, 6CP and L5E is the entire point.
> I completely agree that if it is possible for someone to plan a 223 in inspection (fast people should be able to do that) then this is the way to go.
> However, I do not think TPS would drop due to below F2L TPS due to u moves, because there isn’t any need to purposely slow down for lookahead.
> Even if it does slow down to F2L TPS or lower, I guess 8-9 moves of slower turning would still be as fast as 2 F2L pairs. If FB is as fast as cross, 3rd pair and LSLL will certainly be slower than 6CO, 6CP, L5E; so things should balance out for the methods to at least be comparable.
> ...


cross is faster than FB because there arent B moves


----------



## TheSlykrCubr (Aug 15, 2020)

So if you do the eo before l5e to leave you with 4 or 0 bad edges, why not just use EOLL and EPLL or even just ELL if you're good at recognition?


----------



## Devagio (Aug 15, 2020)

mukerflap said:


> yeah lse is pretty much 0 look since you predict how to do it in CMLL


Just, no


TheSlykrCubr said:


> So if you do the eo before l5e to leave you with 4 or 0 bad edges, why not just use EOLL and EPLL or even just ELL if you're good at recognition?


Influence EO, not do it. Big difference. Influencing EO barely takes any time if at all.


----------



## TheSlykrCubr (Aug 15, 2020)

mukerflap said:


> cross is faster than FB because there arent B moves



I think everyone can agree that B and S moves are the worst in cubing


----------



## Username: Username: (Aug 15, 2020)

TheSlykrCubr said:


> I think everyone can agree that B and S moves are the worst in cubing


B moves are nice if you want to boost efficiency but S moves are in my opinion, the best slice moves (better than E or M moves.)


 *just git gud bro*


----------



## TheSlykrCubr (Aug 15, 2020)

Have you tried using an EO LOL at the start to see what happens?



Username: Username: said:


> B moves are nice if you want to boost efficiency but S moves are in my opinion, the best slice moves (better than E or M moves.)
> 
> 
> *just git gud bro*



Yea I switched up my E and S, I really like S Im just stupid


----------



## Devagio (Aug 15, 2020)

Kaneki Uchiha said:


> you can predict lse in eo mukerflap is correct on that


Yep, you can predict L6EP in EO; not LSE in CMLL as claimed.

And sure it may be pauseless, but I'm willing to bet that L5E can be executed faster since you're braindead throughout the thing, instead of predicting the second half during the first half.

In any case, influenced L5E, which is practically what will show up most of the time is much faster than the average L6E (influencing EO during CMLL is much harder than doing so during belt).


----------



## TheSlykrCubr (Aug 15, 2020)

Devagio said:


> In any case, influenced L5E, which is practically what will show up most of the time is much faster than the average L6E (influencing EO during CMLL is much harder than doing so during belt).



What if you used L5EOP? You wouldn't have to do the EO influencing, but you'd have to do EPLL instead, which has very short algorithms, and a 1/12 chance of a skip


----------



## Devagio (Aug 15, 2020)

TheSlykrCubr said:


> What if you used L5EOP? You wouldn't have to do the EO influencing, but you'd have to do EPLL instead, which has very short algorithms, and a 1/12 chance of a skip


It's an extra alg at the end of the day. Will add to movecount, will add a pause for EP recog, etc. Sure, it will be a decent way to transition to full l5e, but that's about it. If it is possible to learn the entire set, why not do it; it's not like there are 1000 algs in L5E, its less than 70 excluding mirrors and inverses, and even less if we do setups. And all of them 2-gen, so easy to learn as well.


----------



## TheSlykrCubr (Aug 15, 2020)

I found this. It isn't 1-look, but might be fine

If you did an EO LOL at the start, would that be good?


----------



## Devagio (Aug 15, 2020)

Currently generating a few algs, and realising that the initial alg-length estimates were quite off.
Generated 10 psuedo-random 6CO and 6CP algs, so far turns out their average length is 9 moves ETM each!
Will begin generating all 6CO algs tomorrow, hoping for some surprise of this sort.



TheSlykrCubr said:


> If you did an EO LOL at the start, would that be good?


What's an EO LOL? Simply EO? In which case not a good idea because we don't really need EO. Our algorithms do not get much worse without EO. That said, it could be an interesting experiment once the algs are down, to try this method with EO first.


----------



## TheSlykrCubr (Aug 15, 2020)

LOL stands for Line On Left. It's basically doing the left half of the belt


----------



## trangium (Aug 15, 2020)

Devagio said:


> Intermediate version:
> Step 1: FB (~6 moves)
> Step 2: EO-Belt (*~16 moves*) <r,R,U>
> Step 3: 6COLL (~13 moves) <R,U>
> ...


There's no way EO-Belt is 7 moves longer than Belt. Even doing Belt then EO adds only 3-6 additional moves for EO, by using S' U' S to orient 4 edges, R' F R2 F' R' to orient 2 edges where 1 is at the bottom, or a fruruf (or R F R2 F' R) to orient 2 top edges. If an attempt is made to solve EO and Belt together, this number drops even further.

One-look L5E is 245 algorithms, too many for most speedsolvers. With mirrors the number drops to ~130, but it's not that useful to also take inverses into account, since they often have completely different recognition, and having an alg in muscle memory doesn't transfer to also having the inverse in muscle memory (try doing the inverse of your R-perm alg quickly.)

Also, L5EP has a _worst _case of 9 <M, U> moves, not an _average_ case of 13 moves as you indicated. Given that it doesn't take that many extra moves to do EO-belt and the algs saved by doing L5EP instead of L5E, it's probably worthwhile to stick with the intermediate version.


----------



## Devagio (Aug 15, 2020)

trangium said:


> There's no way EO-Belt is 7 moves longer than Belt. Even doing Belt then EO adds only 3-6 additional moves for EO, by using S' U' S to orient 4 edges, R' F R2 F' R' to orient 2 edges where 1 is at the bottom, or a fruruf (or R F R2 F' R) to orient 2 top edges. If an attempt is made to solve EO and Belt together, this number drops even further.
> 
> One-look L5E is 245 algorithms, too many for most speedsolvers. With mirrors the number drops to ~130, but it's not that useful to also take inverses into account, since they often have completely different recognition, and having an alg in muscle memory doesn't transfer to also having the inverse in muscle memory (try doing the inverse of your R-perm alg quickly.)
> 
> Also, L5EP has a _worst _case of 9 <M, U> moves, not an _average_ case of 13 moves as you indicated. Given that it doesn't take that many extra moves to do EO-belt and the algs saved by doing L5EP instead of L5E, it's probably worthwhile to stick with the intermediate version.


I guess having a few algorithmic inserts during belt would keep the intuition out of the thing and a move difference of 6-7 won’t really be there. The way I estimated the numbers was by simply doing a few solves and counting how many moves it took me; not a good measure.

But perhaps this is true. Most like doing an algorithmic belt insert followed by L5EP could prove to be a better idea. The movecount doesn’t seem different at all, and such severe reduction in algorithms can barely be worth it.
I thought the advanced method would be better because I was over-estimating the benefit of L5E over L5EP and underestimating the ease of EO during belt.
Anyway, if EO during belt does turn out be as as Simple, we’d definitely not even do the work of generating the L5E algs.

EDIT: A lot of 6CO and 6CP algs get much better when we allow for F moves (for example, FRURUF vs R2D'RU2R'DRU2R). This is in fact a relatively mild example. If we allow for F moves, we need to expand from L5EP to L5E. If we do not, we will lose out on a lot of great algs there will be.
What I'll do tomorrow is generate the best RUF algs and the best RUD algs for a good number 6CO cases, and compare to see whether EO preservation is worth it.


----------



## mukerflap (Aug 16, 2020)

trangium said:


> There's no way EO-Belt is 7 moves longer than Belt. Even doing Belt then EO adds only 3-6 additional moves for EO, by using S' U' S to orient 4 edges, R' F R2 F' R' to orient 2 edges where 1 is at the bottom, or a fruruf (or R F R2 F' R) to orient 2 top edges. If an attempt is made to solve EO and Belt together, this number drops even further.
> 
> One-look L5E is 245 algorithms, too many for most speedsolvers. With mirrors the number drops to ~130, but it's not that useful to also take inverses into account, since they often have completely different recognition, and having an alg in muscle memory doesn't transfer to also having the inverse in muscle memory (try doing the inverse of your R-perm alg quickly.)
> 
> Also, L5EP has a _worst _case of 9 <M, U> moves, not an _average_ case of 13 moves as you indicated. Given that it doesn't take that many extra moves to do EO-belt and the algs saved by doing L5EP instead of L5E, it's probably worthwhile to stick with the intermediate version.


i dont see how you could ever recog the EO while the centers are switching around


----------



## Devagio (Aug 16, 2020)

mukerflap said:


> i dont see how you could ever recog the EO while the centers are switching around


The only remaining edges are ones with top/bottom colour on it; while centres are (were) switching in the E slice.


----------



## TheSlykrCubr (Aug 16, 2020)

could you insert an f2l pair while placing the bottom right edge of the belt, since it would only need 5coll and 5cpll, which would have shorter and less algorithms


----------



## Devagio (Aug 16, 2020)

TheSlykrCubr said:


> could you insert an f2l pair while placing the bottom right edge of the belt, since it would only need 5coll and 5cpll, which would have shorter and less algorithms


It would have less algs, though not shorter. Plus this ruins the symmetry and ease of belt. 6CO algs are turning out to be amazing so far, I’ll post a few of them in a while here; I don’t see any reason to change this.


----------



## TheSlykrCubr (Aug 16, 2020)

Devagio said:


> It would have less algs, though not shorter. Plus this ruins the symmetry and ease of belt. 6CO algs are turning out to be amazing so far, I’ll post a few of them in a while here; I don’t see any reason to change this.



Fair enough. do you use software to generate the algorithms, or your mind?


----------



## Username: Username: (Aug 16, 2020)

Devagio said:


> The L5E page was made in 2008, it may have relics of cubing advice that no longer holds. The world record time is literally one third of the world record time back then.
> A major thing in cubing is, even if two solutions are same, a one-looked solution is much much better than a two-look solution because of the massive TPS people have today.
> Also, EO can be influenced during belt, which will give only the great cases (i.e. ones with 0 or 4 bad edges).


Still, one look L5E is something that's ridiculous imo, then if every method with L5E can use one look L5E, as it is, "better" also, 2 look solutions aren't that bad you know.


----------



## Devagio (Aug 16, 2020)

TheSlykrCubr said:


> Fair enough. do you use software to generate the algorithms, or your mind?


I coded one up yesterday. Didn’t want to do it using pruning algorithms that most fast alg generating softwares use, since these algs are gonna be pretty short.


Username: Username: said:


> Still, one look L5E is something that's ridiculous imo, then if every method with L5E can use one look L5E, as it is, "better" also, 2 look solutions aren't that bad you know.


I honestly agree, and will do everything in my power to develop the method with only L5EP. Only if there are obvious flaws with this will I go ahead and call out to L5E.


----------



## TheSlykrCubr (Aug 16, 2020)

Devagio said:


> I coded one up yesterday. Didn’t want to do it using pruning algorithms that most fast alg generating softwares use, since these algs are gonna be pretty short.



Thanks


----------



## Devagio (Aug 16, 2020)

Generated a third of the 6CO algs; I drilled all suggested algs and handpicked the best ones (also looked at regrips, wrist overturning, overworking, etc.). Wherever it was not obvious which the best one was, I have provided alternate algorithms.
RUD gen 6CO (which is mostly RU gen anyway) is indeed around 9-10 moves long on average, at least for the sets I've generated so far. This is great news because the method could now potentially average under 50 moves despite being more algorithmic than CFOP!

I generated RUF algorithms for the same cases, and they are on average about 1 move shorter. While they aren't too bad to execute themselves, I believe sacrificing 1 move in an algorithmic TPS for EO is totally worth it. Will consider this later again, but not generating RUF algs anymore so I can finish generating all 6CO algs sooner. Should be done by tomorrow. (There are 71+1 cases, I am done generating 23+1 so far).

As for naming the method, I believe I'll stick to the usual last-name system (Roux, Petrus, Heise, etc.); because I see immense potential here and consider it best to keep it formal.


----------



## trangium (Aug 16, 2020)

Devagio said:


> View attachment 13242
> 
> Generated a third of the 6CO algs; I drilled all suggested algs and handpicked the best ones (also looked at regrips, wrist overturning, overworking, etc.). Wherever it was not obvious which the best one was, I have provided alternate algorithms.
> RUD gen 6CO (which is mostly RU gen anyway) is indeed around 9-10 moves long on average, at least for the sets I've generated so far. This is great news because the method could now potentially average under 50 moves despite being more algorithmic than CFOP!
> ...


Note that some RUF algorithms preserve EO, such as F U' R2 U' R2 U F', or preserve EO if some moves are widened, such as R' F R2 F' R' becoming r' F R2 F' r, so you should also still check RUF algs, or else you might miss some perfectly good algs.


----------



## ribbon method (Aug 16, 2020)

is this a good method


----------



## TheSlykrCubr (Aug 16, 2020)

what's the +1


----------



## TheSlykrCubr (Aug 16, 2020)

I mean as in the +1 algorithms that you have generated


----------



## I'm A Cuber (Aug 16, 2020)

TheSlykrCubr said:


> I mean as in the +1 algorithms that you have generated


Skip case


----------



## TheSlykrCubr (Aug 16, 2020)

oh yeah


----------



## Devagio (Aug 16, 2020)

trangium said:


> Note that some RUF algorithms preserve EO, such as F U' R2 U' R2 U F', or preserve EO if some moves are widened, such as R' F R2 F' R' becoming r' F R2 F' r, so you should also still check RUF algs, or else you might miss some perfectly good algs.


Done generating all algs. This was extremely helpful, it literally brought down the average by almost a move! I genned RUF, RUB, RUL, RUD, RUS and RLD algs. Doing 4-gen would be impractical with my code so not doing that. Currently, I expect 6CO to be 8.5 moves on average  though some of the longer algs are faster, which will push this up slightly.
Drilling and picking the best algs for now, will take quite some time.

Since L5EP needs no work, I intend to work on EO-belt next.

*Thoughts on neutrality:*
Full CN is extremely easy to achieve (as easy as CFOP), and doesn't cause trouble in recognition of any step. This gives us a possible 24 first blocks compared to 8 in roux; i.e. we can take advantage of literally any block on the cube in 2 ways. This makes it more efficient than Roux FB.
Also, being fully CN will help us look deeper into the belt, or make it easier for us to plan an entire psuedo-223; whichever path you choose to achieve EO-ledge (ledge = FB + belt).



ribbon method said:


> is this a good method


Still in the development phase. Does show promise but only time will tell whether it can beat the big few. We should have a much clearer picture in a week when all the algs are generated and all steps almost optimised.


----------



## trangium (Aug 16, 2020)

Devagio said:


> Doing 4-gen would be impractical with my code so not doing that.


Why don't you use Cube Explorer? It's free, and it can easily do 4-gen up to 14 moves, and even 6-gen up to 13 moves. It's pretty easy to use CE to generate 6COLL and 6CPLL algorithms.



Devagio said:


> Done generating all algs


Did you finish only 6COLL, or both 6COLL and 6CPLL? I'm also generating some 6CPLL algorithms due to me being bored.



Devagio said:


> Full CN is extremely easy to achieve (as easy as CFOP)


I wouldn't say full CN is "extremely easy" to achieve. I'm full CN now with CFOP, but the transition was extremely frustrating. One of my most common mistakes was putting in a pair with a flipped edge and twisted corner. People transitioning to CN with the 665 method (is that what it's called?) might have trouble filtering out non-belt edges during belt or recognizing which way a belt edge is oriented, and place a flipped belt edge many times. That being said, I still agree that full CN is easiER with 665 than with Roux or ZZ, maybe slightly easier than CFOP.


----------



## Devagio (Aug 16, 2020)

trangium said:


> Why don't you use Cube Explorer? It's free, and it can easily do 4-gen up to 14 moves, and even 6-gen up to 13 moves. It's pretty easy to use CE to generate 6COLL and 6CPLL algorithms.


I do, this is just me practicing coding because I'm new to it. By impractical, I mean there would be too many algorithms to consider because the moveoptimal ones would be horrible and one or two moves more than optimal would be so many that its not a one person job. I believe that should be done when people start using this method, like what is happening with many OLLs today.


trangium said:


> Did you finish only 6COLL, or both 6COLL and 6CPLL? I'm also generating some 6CPLL algorithms due to me being bored.


I'm done with generating only 6CO*, you generating some 6CP would be great help! If you do, remember to end a D' off, because we want the next step to be MU gen not SU gen. While 6CP can be followed by a D', if we are to do it everytime anyway, it's a better idea to incorporate it in the alg itself.


trangium said:


> I wouldn't say full CN is "extremely easy" to achieve. I'm full CN now with CFOP, but the transition was extremely frustrating. One of my most common mistakes was putting in a pair with a flipped edge and twisted corner. People transitioning to CN with the 665 method (is that what it's called?) might have trouble filtering out non-belt edges during belt or recognizing which way a belt edge is oriented, and place a flipped belt edge many times. That being said, I still agree that full CN is easiER with 665 than with Roux or ZZ, maybe slightly easier than CFOP.


For people that started CN with CFOP, like I did, there was never any problem. That is what I meant by ease; one should never do non-CN stuff with this method because there is no need.
I'm simply calling it Mehta. That's my last name, and I believe that's the norm for fairly fundamental methods. EOLedge->CO->CP->EP, with possibly minor deviations.


----------



## TheSlykrCubr (Aug 17, 2020)

If you were a robot you'd be Mehtaton


----------



## Devagio (Aug 17, 2020)

*EO-Ledge*

The first and the only step that is not fully algorithmic is EO-ledge. There are various ways to achieve it, some better suited than others.
- EO-line + LB + 2 edges
- 3/4 cross + 2 psuedopairs + 2 edges with EO
- EOFB + Belt
- FB + EObelt
- psuedo223 + 2 edges with EO

The last one is most likely the one top solvers will use due to their good inspection abilities. But for a 10-15 second solver, FB+EObelt may be just as viable.

Now, today I tried answering whether EO-belt is worth the effort to save ourselves the trouble of L5E. I basically tried to come up with ways to intuitively and algorithmically do EO while doing best. And believe me when I say I spent a good 6 hours of the day testing things out.

Very proudly though, there is a clear winner. The best way to do EO-belt is also the simplest way to do it:
- solve any 3 edges
- place the last edge while orienting all edges with one algorithms
(much like ZBLS, but MUCH fewer and MUCH shorter algorithms)

The reason isn't clear when you think about it, but I went ahead and generated all algorithms (there are 55 cases), and the average length of these algorithms (mostly RUF) is less than 6 moves!! Note, one would have to do ~3 moves anyway to insert the edge, so with just 3 extra moves, we achieve full EO!
Now this seems like magic to me!

[Actually, the average move length is 5 moves, but some of the longer algorithms are faster]

Also, this applies equally to both FB+EObelt and p223+EOedges, since in both cases all that has to be done is to be be left with one edge, and do the algorithm.

FB ~ 6 moves
EObelt ~ 8+6 moves
6CO ~ 8.5 moves
6CP ~ 9 moves
L5EP ~ 7.5 moves
Various AUF ~ 4 moves
Total ~ 50 moves!

p223 ~ 9 moves
EOedges ~ 2+6 moves
6CO ~ 8.5 moves
6CP ~ 9 moves
L5EP ~ 7.5 moves
Various AUF ~ 4 moves
Total ~ 45 moves!

*So from an initial expected ~60 moves for this method, we now have established this method to have 45-50 moves!*

That is a movecount rivaling Roux with TPS rivalling CFOP!

Sorry for the multiple exclamations, too excited by the algs and ensuing possibilities.

I have attached a picture of the EO-belt algs. There are 8 boxes.
The 4 boxes on top are when the unsolved belt edge is in UF and the slot is in FR. The Bold letters describe the orientation of the UF and FR edges, and the string of 4 letters for each case describes the orientation of UL, UB, UR and DR in order.
The next 2 boxes are when the last belt edge is solved or flipped in place in FR.
The final two boxes are when the last belt edge is in DR, and the bold letters describe its orientation.


I will share the sheet once I have described things better and the other algs are ready.

Apart from move count and TPS, this method doesn't seem to have any lookahead or recognition issues as far as I am aware (still have to check 6CP) and all the algs are sufficiently fast to execute (again, still have to check 6CP). Plus, no rotations!

I very strongly suggest you try this method out, I am sure you could beat your PBs with it. Once I'm done generating 6CP algorithms, I'll try and make a beginner version to help in transition; though it shouldn't be to hard to do it yourselves.


----------



## Username: Username: (Aug 17, 2020)

I just want to ask, where did you get the statistics btw? did you use HARCS?


----------



## Devagio (Aug 17, 2020)

Username: Username: said:


> I just want to ask, where did you get the statistics btw? did you use HARCS?


I made a FB solver and 3/4 belt solver in python, I could share the code. For other steps, I simply took the average alg length. 6CP alg length is tentative.
Not familiar with HARCS, if someone could run it there on my behalf then that’d be great. Just run the intermediate version.
FB (24 possibilities)
3 belt edges (4 possibilities)
Last edge + EO
6CO preserving EO
6CP preserving EO
L5EP using only MU gen


----------



## Sion (Aug 17, 2020)

Maybe if I stop being so lazy with learning methods, I could actually use this-


----------



## trangium (Aug 17, 2020)

I wanted to just generate a few 6CP algs, but then curiosity got the better of me, and before I knew it, I generated 36/48 6CP cases. Then I decided I might as well finish it, so here are my algs:


Spoiler: The list of algs




DF Loc.DB Loc.CaseAUFAlgAUFAlt AlgAUFAlt Alg56SolvedD'AdjacentR U R' F' R U R' U' R' F R2 U' R' D'DiagonalR U' R' U R U' D' R2 U R D R U' D' R2F R U' R' U' R U R' F' R U R' U' R' F R F' D'65SolvedF R U R U' R' F' R U' R U R2 U' R D'R' U R' F' R U R' U' R' F R2 U' R' U' R2 D'AdjacentR U R' D' R U' D2 R' U' R D2 R'R2 U R2 U2 R2 D' R2 U R2 U' R2DiagonalR U' R' U R' U2 R2 U R U R' U' R2 D'26Front OppR2 U2 R2 U' R2 U' R2 D'U2R2 U R2 U R2 U2 R2 D'Right OppU'D R2 U2 R2 U R2 U R2 D2UD R2 U' R2 U' R2 U2 R2 D2Double OppU2x R' U R U' R' U R U' R' U R U' F' x'R' D R U' R D' R' U2 R D R' U R' D' R D'R2 U R2 D R2 D' R2 U' R2 D R2 D2Front BarD' R2 U R2 U' R2 D R2 D'D' R U R' U R2 D R D' RRight BarUR2 D' R2 U R2 U' R2UD' R' D R' D' R2 U R U' R'Double BarR2 U R2 U' R2 D R2 U' R2 U R2 D2R2 U R2 F R U R U' R' F' R U2 R' U2 R' D'62Front OppR2 U2 F U F' R2 F U' F' D'R2 U' R2 D R2 U' R2 U R2 D' R2 D'Right OppU'R' F' R U R2 U' R' F R U' R2 D'Double OppU2R2 U' D R2 U' R2 U R2 D2U2R2 F2 U' F2 D R2 D2Front BarU'R2 U' R2 D'Right BarR2 U' R2 U' R2 D R2 U' R2 U R2 D2U2R' U2 R D R D' R D R U2 R D2U'D' R U R' U' R U2 R D R' U2 R2 D' RDouble BarU'x R' D' R U2 R' D R U2 F' x'R U2 R2 U R D R' U' R D2 R U2 R'U2R2 U' R2 D' R2 U R2 U R2 U2 R252Front OppD' R2 U2 R2 U' R2 U' R2U2D' R2 U R2 U R2 U2 R2 U2Right OppU'R2 U2 R2 U R2 U R2 D'UR2 U' R2 U' R2 U2 R2 D'Double OppU2D' x R' U R U' R' U R U' R' U R U' x'U'R D' R' U R' D R U2 R' D' R U' R D R' D'U'R2 U' R2 D' R2 D R2 U R2 D' R2Front BarU2R2 D R2 U' R2 U R2 D2U2D R D' R D R2 U' R' U R D2U'F R U R U' R' F' R U2 R' U2 R' D'Right BarU'D R2 U' R2 U R2 D' R2 D'U'D R' U' R U R2 D' R' D R' D2R U2 R U2 R' F R U R' U' R' F' D'Double BarU'R2 U' R2 U R2 D' R2 U R2 U' R2R U' R U' R' U R' U R' F' U R' U' R F D'25Front OppU2R U R2 U R' D R' U' R D2 R U' R'U'R2 U R2 D' R2 D R2 U R2 D' R2Right OppU'R2 U F U F' R2 F U' F' D'R D' R' D R' U D' R2 U' R D R' D' R2Double OppUR2 U D' R2 U R2 U' R2UR2 B2 U B2 D' R2Front BarUR U2 R' D' R' D R' D' R' U2 R'U'R2 U R2 U R2 D' R2 U R2 U' R2Right BarR2 U R2 D'Double Barx R D R' U2 R D' R' U2 B' x'R U R' U R U' R' D' R U R' U' R U' R'231=2, 3 AdjU'R2 U2 R2 D'1=2, 3 OppR2 U' R2 U2 R2 U' D' R2 U R2 U' R2D' R U R2 D R' D' R U2 R2 U R2 U R2=3, 1 AdjU'R F' R2 F R U R' F' R2 F R U R2 D'D R2 U' R2 U R2 D' R2 U' R2 U2 R2 D'R' U' R F' R2 F U R' F' R' F U R2 D'2=3, 1 OppR2 U R2 U R2 D R2 U' R2 U R2U'R2 U R U' R U R' U R2 U D' R U' R'R D' R U R' D R' U' R' D R' U R D' R D'All diff, 1 and 2 oppD' R U' R' U2 D R2 U2 R2 D' R U R'UF U R U' R' F' R2 F R U R' U' F' R2 D'All diff, 2 and 3 oppU2R2 U R2 U' R2 U' D' R2 U R2 U' R2U2D' R' D R2 U R U2 R' U' R2 D' R' U' R2321=2, 3 AdjU2D' R U' R U R' D R D' R' U R2 U2 R21=2, 3 OppU2D' R2 U R2 U D R2 U2 D' R2U2D' R2 U R' U D R2 U' D' R U' R2F' U R' U' R U R' U' R U R' U' R F D'2=3, 1 AdjR2 U2 D' R2 U R2 U' R22=3, 1 OppF2 D' r2 D r U' r F2 r' U rUR2 U R2 U' R2 U2 D' R2 U R2 U' R2All diff, 1 and 2 oppR2 U R2 U' R2 U R2 D'U2R2 U' R2 U R2 U' R2 D'All diff, 2 and 3 oppD' R2 U R2 D R2 U' D' R2131=2, 3 AdjR2 U R2 U' R2 U2 R2 D'R2 U' R2 U2 R2 U' R2 D'1=2, 3 OppUR2 U D R2 U' R2 U R2 D22=3, 1 AdjU2R2 U' R2 D' R2 D R2 U' R2 D' R2U2R2 U' R' D' R D R2 U' R' U R' U' D' R2U'R U' R F2 R' U R' U' R2 F2 U2 R2 D'2=3, 1 OppUR2 U R2 D' R2 U R2 U R2 U2 R2All diff, 1 and 2 oppUR D R' D' R2 U R D R2 U' D' R D'U2R U' R F' R2 F U R' F' R' F D'x R2 U R' U' R U R' U' R U R' U' R' F' x'All diff, 2 and 3 oppU2R2 U' D' R2 U R2 U' R2
DF and DB location numbers follow the YruRU numbering scheme.
For the bottom cases, the Case column refers to 3 stickers on the right. For the two sets of cases above that, the case numbers refer to 3 stickers on the front


The average length of the main algs are exactly 10 moves. Although I tried pretty hard to optimize for QTM, still 28/48 of the main algs are in the <R2, U, D> group. The problem with <R2, U, D> algorithms is that R2 moves take ~1.6 times as long as R or R' moves (Source: Jperm's Algometer) so TPS takes a hit.

EDIT: Added more alternate algs for 2 cases


----------



## Devagio (Aug 17, 2020)

trangium said:


> I wanted to just generate a few 6CP algs, but then curiosity got the better of me, and before I knew it, I generated 36/48 6CP cases. Then I decided I might as well finish it, so here are my algs:
> 
> 
> Spoiler: The list of algs
> ...


This is so extremely good!
Well if there aren't any great alternatives, <R2, U, D> should be fine. even if there's an average of 5 R2 in these 28 algs, crudely speaking, that is less than a difference of 2 moves in the overall "effective" movecount which should be fine.
These algs seems to flow pretty well, so I believe you did thoroughly drill them before ranking them. Really really appreciate your effort


----------



## Sion (Aug 17, 2020)

I just had a bit of a moment of realization.

Wouldn't pseudo 223 just make it a variant off of petrus or LEOR with an alternative three look? 

-223 with whatever method (Lmao)
-EO (or if doing EOLR M mslice with EO) with added belt 
-CO
-CP
-L5EP? 

Thinking about it now, I'm not entirely sure what the inherent advantage is of doing it this way.


----------



## Devagio (Aug 17, 2020)

Username: Username: said:


> I just want to ask, where did you get the statistics btw? did you use HARCS?


Checked out HARCS. I'm unable to accomodate for:
1. CN first block.
2. D layer offset.


Sion said:


> I just had a bit of a moment of realization.
> 
> Wouldn't pseudo 223 just make it a variant off of petrus or LEOR with an alternative three look?
> 
> ...


Interesting.
Doing a comparison, I guess:
1. Having a free D slice is quite helpful in efficiency, and making such a psuedo-223 seems difficult with the usual 222+122 or LEOR approach.
2. Having a choice of doing whichever belt edge instead of committing to a block in the start makes this more flexible (look-ahead wise)
3. Having belt edges solved, EO recognition is much easier. Not sure if its shorter so can't comment on that.
4. As we are finding out, the 3 algsets have very short algorithms, I believe instead of blockbuilding the rest of the F2L followed by doing 1-2 LL algs, if we can simply spam 3 algs in a row, it'll be beneficial for high TPS solvers.
That's what I can think of comparing the two; hopefully once I begin using it I'll be able to tell if there are more.

EDIT: I'll code up an elementary solver using this method myself and put it up here for stats checking. Warning: it'll most certainly be very slow, and I will not be feeding it any predefined algs for now, it'll find them each time it runs.


----------



## Zarxrax (Aug 17, 2020)

Your premise seems to be that CFOP is fast because it uses algorithms, so a method that relies more on algorithms could be faster. But is that really the case? To me, it seems that the algorithms at the end of a CFOP solve are one of its main weaknesses, as you don't get much opportunity for lookahead there like you do in the earlier stages of the solve. How is the lookahead through the various steps of your method? If people have to stop and recognize a case at least 3 times, I'm not sure if it would really be any faster. But either way, it sounds very interesting and I am excited to see how this turns out!


----------



## TheSlykrCubr (Aug 17, 2020)

Zarxrax said:


> Your premise seems to be that CFOP is fast because it uses algorithms, so a method that relies more on algorithms could be faster. But is that really the case? To me, it seems that the algorithms at the end of a CFOP solve are one of its main weaknesses, as you don't get much opportunity for lookahead there like you do in the earlier stages of the solve. How is the lookahead through the various steps of your method? If people have to stop and recognize a case at least 3 times, I'm not sure if it would really be any faster. But either way, it sounds very interesting and I am excited to see how this turns out!



I think it's just because many people think that algorithms are better because of muscle memory and not thinking, just recognition. Look-ahead seems decent, from the example solves


----------



## Nmile7300 (Aug 17, 2020)

This seems like a cool method. Imagine if "Mehta" becomes the "Meta"!


----------



## TheSlykrCubr (Aug 17, 2020)

Nmile7300 said:


> This seems like a cool method. Imagine if "Mehta" becomes the "Meta"!



There can be only one Mehta pun


----------



## Devagio (Aug 17, 2020)

Zarxrax said:


> Your premise seems to be that CFOP is fast because it uses algorithms, so a method that relies more on algorithms could be faster. But is that really the case? To me, it seems that the algorithms at the end of a CFOP solve are one of its main weaknesses, as you don't get much opportunity for lookahead there like you do in the earlier stages of the solve. How is the lookahead through the various steps of your method? If people have to stop and recognize a case at least 3 times, I'm not sure if it would really be any faster. But either way, it sounds very interesting and I am excited to see how this turns out!


The only step that is neither algorithmic, nor done in inspection by intermediate solvers is putting 3 belt edges. It is basically like F2L, but we only have to solve the edge, and we don't usually need a trigger to insert it since the R layer is free, so lookahead doesn't seem to be an issue here. In my experience, this takes between 6 and 9 moves, I will be using a computer program to verify this hopefully tomorrow. The algorithmic step affects only specific piece types so it should be possible to at least partially predict the case in the next algorithm.

Coming to fundamental question, what is the validity of my premise: I believe CFOP algorithms step is bad because the algorithms themselves are long and bad (compared to say typical 3style algs). This is why it may appear as a weakness. Despite this, and the overall movecount handicap, if people still continue getting the best times with this method, I believe that is because they can reliably spam TPS in the algorithmic steps to make up for the inefficiency. I may be mistaken somewhere, but yes, this is the premise on which the method stands.


----------



## TheSlykrCubr (Aug 17, 2020)

Devagio said:


> The only step that is neither algorithmic, nor done in inspection by intermediate solvers is putting 3 belt edges. It is basically like F2L, but we only have to solve the edge, and we don't usually need a trigger to insert it since the R layer is free, so lookahead doesn't seem to be an issue here. In my experience, this takes between 6 and 9 moves, I will be using a computer program to verify this hopefully tomorrow. The algorithmic step affects only specific piece types so it should be possible to at least partially predict the case in the next algorithm.
> 
> Coming to fundamental question, what is the validity of my premise: I believe CFOP algorithms step is bad because the algorithms themselves are long and bad (compared to say typical 3style algs). This is why it may appear as a weakness. Despite this, and the overall movecount handicap, if people still continue getting the best times with this method, I believe that is because they can reliably spam TPS in the algorithmic steps to make up for the inefficiency. I may be mistaken somewhere, but yes, this is the premise on which the method stands.



And here there's no N perm


----------



## Sion (Aug 17, 2020)

Devagio said:


> Interesting.
> Doing a comparison, I guess:
> 1. Having a free D slice is quite helpful in efficiency, and making such a psuedo-223 seems difficult with the usual 222+122 or LEOR approach.


Looking at your method sheet, the D slice really isn't "free" per-se. Only one alg set use it and some last adjustments at the end. I wouldn't exactly call that free.



Devagio said:


> 2. Having a choice of doing whichever belt edge instead of committing to a block in the start makes this more flexible (look-ahead wise)


This is true, and I love the idea of having a "pseudo block" in the orientation you're presenting it in. It would definitely speed up blocks.



Devagio said:


> 3. Having belt edges solved, EO recognition is much easier. Not sure if its shorter so can't comment on that.


While that is true, it adds an extra amount of moves and looks, which could end up slowing solves when cubies can be solved simultaneously.



Devagio said:


> 4. As we are finding out, the 3 algsets have very short algorithms, I believe instead of blockbuilding the rest of the F2L followed by doing 1-2 LL algs, if we can simply spam 3 algs in a row, it'll be beneficial for high TPS solvers.


I think there's some truth to this, and it would be interesting to see application, although setup moves are still a thing here, which technically could add moves.


Imho, I personally love the way you structured your pseudoblock and I do feel like you're on to something, since if you were going to use a petrus/LEOR-style F2L+LL approach, it wouldn't impede on LL recognition at any major capacity. 

The final steps seem interesting, and it would be nice to see it get developed, though I'm not entirely sure how well it would be picked up. 

I can definitely see people adopting your pseudo 2x2x3, though.


----------



## trangium (Aug 18, 2020)

1. You should probably update the original post, since the method has evolved so much since then.
2. I think transitioning between algorithms is one of the most important things to think about with this method, because a large portion of the solve is algorithmic, and the only pauses will be in between algorithms. Last Belt Edge + EO seems not too difficult to look ahead to during the previous step. 6CO seems very difficult to track during the previous step. Tracking 6CP during 6CO seems doable with enough practice. Tracking L5EP during 6CP shouldn't be too bad either, but the left thumb needs to adjust from an RUD grip to an MU grip.
3. Oh snap, the algs are taking over! With the 55 algorithms for Last Belt Edge + EO, that brings the total algorithm count to *189*. That's over twice CFOP's *78 *algs. You said you wanted a bearable algorithm count, but 189 is stretching it, at least for me. That being said, it could be fine since most of the algs are short.


----------



## Owen Morrison (Aug 18, 2020)

trangium said:


> 1. You should probably update the original post, since the method has evolved so much since then.
> 2. I think transitioning between algorithms is one of the most important things to think about with this method, because a large portion of the solve is algorithmic, and the only pauses will be in between algorithms. Last Belt Edge + EO seems not too difficult to look ahead to during the previous step. 6CO seems very difficult to track during the previous step. Tracking 6CP during 6CO seems doable with enough practice. Tracking L5EP during 6CP shouldn't be too bad either, but the left thumb needs to adjust from an RUD grip to an MU grip.
> 3. Oh snap, the algs are taking over! With the 55 algorithms for Last Belt Edge + EO, that brings the total algorithm count to *189*. That's over twice CFOP's *78 *algs. You said you wanted a bearable algorithm count, but 189 is stretching it, at least for me. That being said, it could be fine since most of the algs are short.


I think 189 isn't too bad especially considering how easy some of the algs are and the fact that he wants this to be an algorithmic method.


----------



## efattah (Aug 18, 2020)

Independently of this thread I was about to generate the algorithms to 1-look L5E for LMCF. Currently 38% of LMCF solves finish in L5E which is currently done in 2 steps. It has taken several years but I think I found a recognition system for L5E (1-look) that is very fast. Having said that there are 245 cases which would increase LMCF from 774 algorithms to 970+.
In terms of the method in this thread, I think anything under 500 algorithms is absolutely realistic and to be expected for a method that has 3 algorithmic steps. The 'problem' with a 500 algorithm method isn't learning the algorithms-- it is spending the HUGE amount of time generating-testing-regenerating algorithms for each case. This is because it is often the case that a 16-move algorithm is faster than a 10-move, and when generating algs, anything over 13 moves and you have a titanic number of cases and no good A.I. utility exists to sort long lists of algorithms into finger friendly versions including possible wide moves and rotations. If/when someone develops a human hand model that can convert an alg to finger tricks and predict the speed, and then sort an algorithm list, it will be a titanic advance for new method generation because you save 5+ years of humans doing all the tweaks.


----------



## TheSlykrCubr (Aug 18, 2020)

Did you ever consider adding the last edge when you make the fb, so that you would only have to do ell? I know recognition is quite hard, but it has already been established as 1-look. Also, if you used EO belt, you'd only have to use the 4 EPLL algs. I'm just not sure if it'll mess us the 6CLL algorithms.
BTW, why 6COLL and 6CPLL if it isn't all on the last layer?


----------



## Devagio (Aug 18, 2020)

trangium said:


> 1. You should probably update the original post, since the method has evolved so much since then.
> 2. I think transitioning between algorithms is one of the most important things to think about with this method, because a large portion of the solve is algorithmic, and the only pauses will be in between algorithms. Last Belt Edge + EO seems not too difficult to look ahead to during the previous step. 6CO seems very difficult to track during the previous step. Tracking 6CP during 6CO seems doable with enough practice. Tracking L5EP during 6CP shouldn't be too bad either, but the left thumb needs to adjust from an RUD grip to an MU grip.
> 3. Oh snap, the algs are taking over! With the 55 algorithms for Last Belt Edge + EO, that brings the total algorithm count to *189*. That's over twice CFOP's *78 *algs. You said you wanted a bearable algorithm count, but 189 is stretching it, at least for me. That being said, it could be fine since most of the algs are short.


1. Will do today after I post 6CO algs.
2. Yes, I agree. As you pointed out, EO-belt algs and L5EP algs are not hard to transition to. Beyond this, I reasoned that transition to 6CO is similar to transition to OLL, and transition to 6CP is similar to transition to PLL; nonetheless I will be making a post on this so this could be explored in greater depth.
3. If you really think about it, CFOP is at least 78+41x4 algorithms. EO-belt algs are as intuitive as F2L algs if not more.


efattah said:


> Independently of this thread I was about to generate the algorithms to 1-look L5E for LMCF. Currently 38% of LMCF solves finish in L5E which is currently done in 2 steps. It has taken several years but I think I found a recognition system for L5E (1-look) that is very fast. Having said that there are 245 cases which would increase LMCF from 774 algorithms to 970+.
> In terms of the method in this thread, I think anything under 500 algorithms is absolutely realistic and to be expected for a method that has 3 algorithmic steps. The 'problem' with a 500 algorithm method isn't learning the algorithms-- it is spending the HUGE amount of time generating-testing-regenerating algorithms for each case. This is because it is often the case that a 16-move algorithm is faster than a 10-move, and when generating algs, anything over 13 moves and you have a titanic number of cases and no good A.I. utility exists to sort long lists of algorithms into finger friendly versions including possible wide moves and rotations. If/when someone develops a human hand model that can convert an alg to finger tricks and predict the speed, and then sort an algorithm list, it will be a titanic advance for new method generation because you save 5+ years of humans doing all the tweaks.


We will not be generating L5E, as pointed out it’s not necessary or worth it for this method.
Yes, optimising algorithms is a horror story. To think about better PLL algs popping every now and then is really strange. I guess it shouldn’t be too hard for someone to develop an AI that tests all algorithms upto some moves over the optimal. We wouldn’t even need a human hand model, we could simply regress based on current alg preferences.
Best of luck with L5E.


TheSlykrCubr said:


> Did you ever consider adding the last edge when you make the fb, so that you would only have to do ell? I know recognition is quite hard, but it has already been established as 1-look. Also, if you used EO belt, you'd only have to use the 4 EPLL algs. I'm just not sure if it'll mess us the 6CLL algorithms.
> BTW, why 6COLL and 6CPLL if it isn't all on the last layer?


This will
- increase alg length and belt moves because R layer is no longer free
- basically will be like cross+2c+keyhole edges, not a very efficient option
- having a step just for 4 cases seems like a waste


----------



## semiprime799 (Aug 18, 2020)

efattah said:


> Independently of this thread I was about to generate the algorithms to 1-look L5E for LMCF. Currently 38% of LMCF solves finish in L5E which is currently done in 2 steps. It has taken several years but I think I found a recognition system for L5E (1-look) that is very fast. Having said that there are 245 cases which would increase LMCF from 774 algorithms to 970+.
> In terms of the method in this thread, I think anything under 500 algorithms is absolutely realistic and to be expected for a method that has 3 algorithmic steps. The 'problem' with a 500 algorithm method isn't learning the algorithms-- it is spending the HUGE amount of time generating-testing-regenerating algorithms for each case. This is because it is often the case that a 16-move algorithm is faster than a 10-move, and when generating algs, anything over 13 moves and you have a titanic number of cases and no good A.I. utility exists to sort long lists of algorithms into finger friendly versions including possible wide moves and rotations. If/when someone develops a human hand model that can convert an alg to finger tricks and predict the speed, and then sort an algorithm list, it will be a titanic advance for new method generation because you save 5+ years of humans doing all the tweaks.


I'm not familiar enough with the alg generators out there to say for sure but...

Couldn't this kind of ranking and sorting of algs be accomplished using statistics?
Say rank an alg higher in the list because it contains sequences we know to be highly fingertrickable?
I guess if you have some sort of database of all the algs, say CFOP uses. (But split up into little tiny 3 move bits.) You could match that model to the algs that you are generating. Whichever alg contains the most high TPS sequences should be sorted up to the top and so on.

When I was thinking about this a bit in my head, I thought of something like a markov chain. eg have a model of the most popular CFOP algs with probabilities for the next fingertrick sequence before regrip.


----------



## efattah (Aug 18, 2020)

I have thought a lot about the algorithm sorting 'utility', and even with my A.I. background the only truly viable solution I see is a human hand model that incorporates all known finger tricks including certain extremely weird fingertricks that are used on very very few algorithms/methods. Sure, some type of statistical regression based on known algorithms would already be a HUGE improvement over basic Excel spreadsheet sorting, but in my opinion will never match a human's ability to sort/test. Only a full hand model with programmed finger tricks could match a human in my opinion. Not actually *that* difficult a project-- would be a good size project for a master's thesis and probably take someone 3 months full time.


----------



## Devagio (Aug 18, 2020)

*Finally, the algorithms*

Here, I'm attaching the list of all 6CO (6 corners orientation) and EOLE (Edge orientation with last edge) algorithms. I've tried my best to pick out the fastest algorithms, and included alternate algorithms where there is no clear best.



Spoiler: 6CO algs




DDHR' U2 R U2 R U2 R U2 R'R' U' R2 U' R U2 R2 U' R' PiR U2 R2 U' R2 U' R2 U2 R SuneR U R2 U' R2 U RAntisuneR U2 R' U' R U' R'UF U' R2 U R2 U F'D R D' R2 U R2 D R' D'TR D' R U2 R' D R'R U R D R' U' R D' R2 LR D' R U' R' D R'Onilavg6.63​RRHR U' R' U2 R' U' R U2 R U' R PiR U' R' U' R U' R U2 R' U R'SuneR U' R' D' U' R U2 R' DAntisuneR' U R D U R' U2 R D'UR U' R2 U' R U2 R2 U' RTR U2 R' U' R2 U2 R' U R'R U R U2 R2 U' R U2 R'LR U R U2 R' U R'OD' R U' R' D R' U R2 U' RR U R U' R' U R U' R' U R'avg9.13​FBHR U R' U' R2 U R2 U' R2 U2 R' U' R'R' U' R U R2 U' R2 U R2 U2 R U RPiR U R2 U2 R2 U R' U2 R' U' RSuneD' R U' R' D U' R U2 R'R2 U R' U2 R U' R2 U R U2 R'AntisuneD R' U R D' U R' U2 RR2 U' R U2 R' U R2 U' R' U2 RUR' U2 R2 U' R2 U' R2 U2 R'TR U2 R U2 R U2 R U2 RLR' U R U R2 U' R2 U R' U2 ROR2 U' R D' R U2 R' D RR U2 R U' R' U2 R U' R' U2 R'avg9.75​RDhandL' U R2 U' R2 L R' D' R U' R' D RasiaR U' R' U' R U2 R'S D R' U2 R U' R' U' R D'p R' U R U2 R2 U' R U2 RdogR U' R' U2 R U' R'hammerB' R2 U' R2 U BR D U' R' U2 R D' U' R' clockR' U2 R' U R2 U' R' U2 ReagleR' U2 R U R2 U' R U2 R avg7.75​FDlegR D' R U R' D R'americaD R' U R U R' U2 R D' R2 U' R U2 R' U' R U' RNR U2 R' U R U R'bR S' U2 S RR U R' U2 R U R'catD R' U R U2 R' U R D'R' U' R2 U2 R' U R2 U2 R2 U' R'sickleB' U' R2 U R2 BR2 U R' U R U2 R' U R'fanR U' R' U' R U' R' U R U2 R'pigeonR U2 R' U R U' R' U' R U' R'avg8.13​DRlegL U' R2 U R2 L' R D R' U' R D' R'americaR' U R U R' U2 RND' R U2 R' U R U R' DbR U' R' U2 R2 U R' U2 R' D' R U R' U2 R U R' D catR' U R U2 R' U R sickleF R2 U R2 U' F'fanR U2 R U' R2 U R U2 R'pigeonR U2 R' U' R2 U R' U2 R'avg7.75​DBhandR' D R' U' R D' R asiaR2 U2 R' U R' U R U2 R'S R' U2 R U' R' U' Rp R' S' U2 S R'R' U' R U2 R' U' RdogD' R U' R' U2 R U' R' DR' U R U R' U' R U R' U2 RhammerF U R2 U' R2 F'clockR' U R U R' U R U' R' U2 R eagleR' U2 R U R' U' R U' R' U' Ravg8.13​FRhandR U' R U' R' U2 R'asiaR U2 R U' R2 U2 R U R'S R U' R' U2 R' U R U' R2 U' R'p R U' R2 U R' U R' U2 R R U2 R' D' U R U R' DdogR U R U R' U R U' R' U2 R' hammerR U2 R' U R' U R2 U' RR U2 R' U R2 U' R' U2 R'clockR' U R U' R U' R U R'R U R U R2 U R U R' eagleR U2 R' U R2 U2 R2 U2 R U R'avg9.5​RBlegR' U R' U R U2 RamericaR2 U' R' U R U2 R' U R'NR' U R U2 R U' R' U R2 U RR' U' R U' R' U' R2 U' R2 U R'bD' R U' R' D U2 R U' R'D R' U2 R D' U' R' U' R catR' U' R U R2 U' R2 U R' U' RsickleR U2 R U R2 U' R U2 R'R' U2 R U' R2 U R U2 RfanR U' R' U R' U R' U' RpigeonR' U2 R U' R2 U2 R2 U2 R' U' Ravg9.5​






Spoiler: How to read 6CO



The 72 cases (71+1) are divided into 9 subsets, depending on the orientations of DFR and DBR corners. For example, the subsection "RB" is when the DFR corner is oriented towards R and the DBR corner is oriented towards B.

In 3 of the subsections, there are familiar OCLL patterns like T, U, L, O, H, Pi, etc. The other 6 subsets (3+3) have different patterns which I have tried to name based on how they look. Note that there is a symmetry here. For instance, The mirror image of "dog" in one of the subsets is "cat" in the other subset; because dog and cat are similar words. Other such pairs are hand-leg, pigeon-eagle, sickle-hammer, etc. This will become obvious with time.

Under every subset, the average movelength of the main algs is mentioned. The overall average movelength of all of these algorithms is 8.47 STM. There are shorter algorithms for some of these cases, however I have tried to pick the fastest ones. It is interesting to note that in the 5 subsets (40/72 cases) where there is at least one of the D corners oriented, the average alg length is on average 20% less than the remaining 4, so an advanced solver may try to force at least one of the D corners to be oriented for better cases.





Spoiler: EOLE algs




GGGGGGR U' R'GGBBU F R F' U2 R'U R' F R2 F' U2 R'GBGBU2 F R F' U R'U2 R' F R2 F' U R'GBBGU' R U2 R2 F R F'U F R' F' R2 U2 R'BGGBU R F' U2 F R' BGBGR2 U' F R F' R2BBGGU2 F R' F' R2 U R'BBBBU S' U S R U2 R'U R' F R2 F2 U2 F R' avg5.25​GBGGGBU2 R F' U F R'GGBGU' R U R2 F R F'GBGGF' U2 F R U' R' BGGGU' R' F R F'GBBBU2 F R F2 U' F U2 R' BGBBU F R F2 U2 F R' BBGBU2 R' F R2 F2 U F R'U2 R F' U F2 R2 F' R BBBGU S' U' S U2 R' F R F'avg6.125​BGGGGBF R F' R'GGBGF R' F' RGBGGR U R' F' U' F F U R' U' F' U R BGGGU' F R' F' R2 U' R'GBBBU2 R F' U2 F2 R' F'BGBBU' S' U S R U R'U R U2 F' U F2 R' F'BBGBU' R' F R2 F2 U' F R'U2 S' U' S U R U' R'BBBGU S' U S U' F R' F' R avg5.875​BBGGGGU' F' U FE R' U' RGGBBF' U F2 R F' R'U R F R' F2 U' FGBGBU2 R F R' F2 U2 FF R F2 U2 F U2 R'GBBGU R' F R F2 U' FF R' F2 U2 F U2 R BGGBu' F R F'BGBGF R' F2 U' F U Ru' F U R2 U' R F'BBGGF' U2 F2 R' F' RU2 R' F R F2 U2 FBBBBU S' U S u' R' U' Ravg5.625​solved0Bnil1BR' F R2 F' R'2B (adj)R F R2 F' RF U R U' R' F'2B (opp)F R U R' U' F'3BS' U SF R F' U2 F R' F'4BR2 S' U S U2 R2avg4.17​flipped0BF R F2 U F U2 R'R U R' F R F' R'1BF' U2 F R U R'R U R' F R' F' R2B (adj)F R F2 U' F R'2B (opp)R F' U F2 R' F'3BR' F R F' U' R' F R F'4BS' U S R U2 R' F' U' Favg7.17​G0BR' U' R U R1BR F R' F'R U F R' F'2B (adj)R2 F R F' R2R U' F R' F'2B (opp)R F U R' U' F'3BF R' F2 U2 F R U2 R4BF R' F' R2 U2 F R' F'avg6.00​B0BF u' R u F21BF R F' U' R'2B (adj)u' F R' F'2B (opp)u' F U R' U' F'F R F2 U2 F U' R'3BR F' U' F2 R2 F' R4Bu' F R' F' U2 R F R2 F' R avg6.17​






Spoiler: How to read EOLE



The 56 cases are divided into 8 subsets (8x4 + 6x4). The first four are when the last edge is in UF and the slot is in FR. The subsets are denoted by the orientation of the last edge (in UF) and the edge in FR respectively. Each case in these sets is denoted by the orientation of UL, UB, UR and DR edges respectively. The next two cases are when the last edge is in FR itself, either solved or flipped. The final two cases are when the last edge is in DR.

Note that all the algorithms are entirely intuitive, and should be treated so when beginning. The overall average movecount of these inserts is 5.80 moves.



I will soon edit the OP and include all of this along with the developed method.

As for the statistics of this method and their verification, since it is not exactly possible to do it using HARCS, I am going to attach the code of my FB solver and belt solver, and the method statistics I get when I run my code on say WC2019 3x3 finals. The final movecount will be the sum of (average of simulated FB movecount) + (average of simulated belt movecount) + average alg lengths of 6CO, 6CP, L5EP + expected number of AUF in the middle of these algorithms. The algorithms are attached above so the average alg length can be verified if necessary.

I am also going to use HARCS on a slightly constrained version of this method (i.e. not fully CN FB, and no free D layer) and publish the results here. The numbers should be about 2-3 moves higher than the movecount average without these constraints.


----------



## TheSlykrCubr (Aug 18, 2020)

is EOLE the EO ledge?


----------



## Cuberstache (Aug 18, 2020)

TheSlykrCubr said:


> is EOLE the EO ledge?


EO + Last Edge, it's the end of EO ledge where you insert the last edge while doing EO


----------



## TheSlykrCubr (Aug 18, 2020)

CuberStache said:


> EO + Last Edge, it's the end of EO ledge where you insert the last edge while doing EO


ok thank you


----------



## Sion (Aug 18, 2020)

Devagio said:


> *Finally, the algorithms*
> 
> Here, I'm attaching the list of all 6CO (6 corners orientation) and EOLE (Edge orientation with last edge) algorithms. I've tried my best to pick out the fastest algorithms, and included alternate algorithms where there is no clear best.
> 
> ...




Could you include a sheet with picture references somwhere? That would be appreciated.


----------



## Devagio (Aug 18, 2020)

Ran a 10000 solve simulation of a constrained version of the method.

Constraints:
- only one FB instead of a possible 24 FB
- exactly the same 3 belt edges solved first instead of 4 possible combinations

And then there were the general constraints that there is no influencing of one step on the next (which is kind of the point though).

The best part is, this number actually holds for the method because there isn't much scope of inefficiency. FB is planned in inspection so any intermediate solver is going to be almost optimal, and the last 4 steps are algorithms. The only place where fluid intuition is needed is the first 3 belt edges (3 pieces).
In comparison, theoretical and practical CFOP numbers are nowhere close because of the move inefficiencies even top solvers have during F2L (8 pieces).

Here, "proof of statistics". I hope the suspicions of me manipulating the numbers are put to rest. If not, I am certainly ready to go to further lengths. Skepticism is always good, as long as there is a healthy open conversation about it.
With utmost innocence, I urge please let me know if you feel a certain something is not adding up about the method, publically or in private. I agree there is a possibility of a mistake, but I assure you it will not be on purpose. Simply putting me down without letting me know of the concerns will neither help this method, nor the community. And that would be a wasted thought then.




Sion said:


> Could you include a sheet with picture references somwhere? That would be appreciated.


Will try to do that soon; most likely will make a simple github website. Balancing this with another school project of mine, so it will take some time


----------



## AlphaCuber is awesome (Aug 19, 2020)

Devagio said:


> FB is planned in inspection so any intermediate solver is going to be almost optimal


I definitely don’t believe this.


----------



## mukerflap (Aug 19, 2020)

Devagio said:


> View attachment 13265
> 
> Ran a 10000 solve simulation of a constrained version of the method.
> 
> ...


optimal fb is pretty much impossible i know every single technique for it and have done like 40 thousand different first blocks and i know for sure i couldnt get an average of 7 on afixed block
this isnt cross
same with all the best roux solvers

also make a beginner version of this method with less than 50 algs


----------



## TheSlykrCubr (Aug 19, 2020)

If you do the arrow with 2 F2L pairs, that would be about as hard as an XCross, which the advanced solvers can definitely do. Then you do belt edge, EOLE and then algs


----------



## Devagio (Aug 19, 2020)

*A Beginner version

Step 1:* Make a 1x2x3 in DL (i.e. solve DL, DF, DB edges and DFL, DBL corners. E slice centres are not necessarily solved). If this is hard, make a 1x2x2 in DLF or DLB during inspectiom, and then extend it with a pair. I suggest to try and be at least partially color neutral here. Roux FB tutorials should certainly help.

*Step 2:* Intuitively solve 3 belt edges using <R, U, u> moveset. <F, f> moves are okay too. Remember, you do not need to insert edges with triggers since the R layer is free. Whenever possible, try and solve 2 edges at once, this should become natural with practice.

*Step 3:* Solve the last belt edge while intuitively doing EO. CFOP edge control tutorials should help. Some useful triggers to start with are F<U>F', R'FRF', S'US, R2UR2, etc. Keep this intuitive for now, you can then start to slowly optimise your solutions using the EOLE algorithms.

*Step 4a:* If only 0 or 1 of the 6 remaining corners are oriented (you’ll skip this 66% of the time), use either Sune or Antisune to ensure at least 2 of the 6 corners are oriented.

*Step 4b:* Use an R2<U>R2 trigger to put two of the oriented corners in DFR and DBR.

*Step 4c:* You now have 7 possible cases for CO, use an alg.

*Step 5a:* Use an R2<U>R2 trigger to solve the DBR corner.

*Step 5b:* You now have 8 possible cases for CP, use an alg.

*Step 6a:* Insert the D edge to the bottom layer using M'U2M.

*Step 6b:* You now have 4 possible EP cases, use an alg.




Spoiler: Beginner CO algs (step 4c) 




HR' U2 R U2 R U2 R U2 R'R' U' R2 U' R U2 R2 U' R'PiR U2 R2 U' R2 U' R2 U2 RSuneR U R2 U' R2 U RAntisuneR U2 R' U' R U' R'UF U' R2 U R2 U F'D R D' R2 U R2 D R' D'TR D' R U2 R' D R'R U R D R' U' R D' R2LR D' R U' R' D R'
Or use regular OCLL algs.





Spoiler: Beginner CP algs (step 5b)




Location of DFR cornerCaseMain algAlt algDFRsolvedD'DFRopposite on rightR U R' F' R U R' U' R' F R2 U' R' D'DFRdiagonalR U' R' U R U' D' R2 U R D R U' D' R2F R U' R' U' R U R' F' R U R' U' R' F R F' D'UBLopposite in frontR2 U2 R2 U' R2 U' R2 D'U2 R2 U R2 U R2 U2 R2 D'UBLopposite on rightU'D R2 U2 R2 U R2 U R2 D2UD R2 U' R2 U' R2 U2 R2 D2UBLdiagonalU2 x' R' U R U' R' U R U' R' U R U' F' xR' D R U' R D' R' U2 R D R' U R' D' R D'UBLheadlights in frontD' R2 U R2 U' R2 D R2 D'D' R U R' U R2 D R D' RUBLheadlights on rightU R2 D' R2 U R2 U' R2UD' R' D R' D' R2 U R U' R'UBLsolvedR2 U R2 U' R2 D R2 U' R2 U R2 D2R2 U R2 F R U R U' R' F' R U2 R' U2 R' D'






Spoiler: Stats



Total number of algs: 7+8+4 = 19

Expected movecounts:
Step 3: 10 moves
Step 4: 13 moves
Step 5: 14 moves
Step 6: 13 moves

Total from step 3 to end: 40 moves
Total: 60-65 moves for a beginner
Source: HARCS





Spoiler: Beginners' Example



Scramble: R' B' F2 L2 U2 R' B2 R' B' L' B2 F' R2 U' F' D R2 B' D2 B F R F U' L

L2 D R' // 1a (making a 1x2x2)
R' U2 R D L' y' // 1b (extending to 1x2x3)
U2 R' // 2a (belt edge 1)
u2 U R // 2b (belt edge 2)
u' R // 2c (belt edge 3)
F' U F R U2 R' // 3 (intuitive EOLE)
R' U' R U' R' U2 R // 4a (orienting at least 2 corners)
R2 U2 R2 // 4b (putting in the 2 corners)
R U2 R2 U' R2 U' R2 U2 R // 4c (orienting L4C)
R2 U' R2 // 5a (permuting DBR corner)
U R2 D' R2 U R2 U' R2 // 5b (permuting other corners)
U2 M' U2 M // 6a (permuting D layer edge)
M2 U M2 U M' U2 M2 U2 M' // 6b (EPLL)

This solve had no skips. Without cancellations, movecount = 3+5+2+3+2+6+7+3+9+3+8+4+9 = 64 moves.





AlphaCuber is awesome said:


> I definitely don’t believe this.





mukerflap said:


> optimal fb is pretty much impossible i know every single technique for it and have done like 40 thousand different first blocks and i know for sure i couldnt get an average of 7 on afixed block
> this isnt cross
> same with all the best roux solvers


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.


TheSlykrCubr said:


> If you do the arrow with 2 F2L pairs, that would be about as hard as an XCross, which the advanced solvers can definitely do. Then you do belt edge, EOLE and then algs


Very inefficient, and doesn't allow for free D layer of flexibility in order of belt edges.


----------



## zzcuberman (Aug 19, 2020)

personally i think this is a good method, but the double turns in the cp step really hinder it for me.


----------



## Devagio (Aug 19, 2020)

zzcuberman said:


> personally i think this is a good method, but the double turns in the cp step really hinder it for me.


You can always learn alternate algs, which will appear more and more as the method progresses. Optimal T perm for example is 10 moves, but we still use a 14 move algorithm and yet its one of our best algs. I’m sure it must’ve taken some time to find the best alg as it will for 6CP.
For now, about half of the cases have main algs that don’t use R2 very often, and many others have decent alternatives. This is a pretty good start imo.


----------



## zzcuberman (Aug 19, 2020)

Devagio said:


> You can always learn alternate algs, which will appear more and more as the method progresses. Optimal T perm for example is 10 moves, but we still use a 14 move algorithm and yet its one of our best algs. I’m sure it must’ve taken some time to find the best alg as it will for 6CP.
> For now, about half of the cases have main algs that don’t use R2 very often, and many others have decent alternatives. This is a pretty good start imo.


yes, ofcourse!


----------



## trangium (Aug 19, 2020)

zzcuberman said:


> personally i think this is a good method, but the double turns in the cp step really hinder it for me.


Let's put some numbers on this: Of the 47 6CP cases, 28 of the main algs are in the <R2, U, D> group. 12 of these have alt algs not in the <R2, U, D> group, which leaves 16 cases left. 3 of these are 4-movers, which barely take any time, leaving 13 cases. 4 of these are some form of R2 U R2 U R2 U2 R2 D', which are still really fast despite the R2s. If you really wanted, you could use R U' R' U R U2 R' U' R U R' D', but I didn't include that because it's too long to be worth it. This leaves only 9 annoying <R2, U, D> cases, some of which we will eventually find better algs for.


----------



## Devagio (Aug 19, 2020)

The original post has been updated.

Since the major steps have been frozen, interested people can begin transitioning to the method via the beginner variation. Do let it be known if you’re trying it out, whether you intend to continue to the full version, etc; this will motivate others to try it out and subsequently the method will develop quicker.

For those who wish to promote it, you could make YouTube tutorials or talk to YouTubers about it; since the method is fairly straightforward, it shouldn’t be difficult for anyone to make a tutorial.


----------



## trangium (Aug 19, 2020)

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 (Aug 19, 2020)

trangium said:


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


the FBs arent equal because the ergonomics are different
SB last pair is pretty much algorithmic
also replace eo with eolr


----------



## zzcuberman (Aug 19, 2020)

mukerflap said:


> 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?


----------



## Etotheipi (Aug 19, 2020)

zzcuberman said:


> how arent they equal if its the first step?


With Mehta you solve FB in a different location than in Roux, so there's different ergonomics.


----------



## PetraPine (Aug 19, 2020)

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


----------



## efattah (Aug 20, 2020)

Etotheipi said:


> 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 (Aug 20, 2020)

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 (Aug 20, 2020)

trangium said:


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


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.


efattah said:


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


Owen Morrison said:


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


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.





Spoiler: Redundant stats comparison



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.


----------



## AlphaCuber is awesome (Aug 20, 2020)

Devagio said:


> 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 (Aug 21, 2020)

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 (Aug 21, 2020)

Devagio said:


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


ok record solves with it


----------



## Silky (Aug 21, 2020)

Owen Morrison said:


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


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 =>



Silky said:


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


----------



## efattah (Aug 24, 2020)

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 (Aug 24, 2020)

efattah said:


> 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 (Aug 24, 2020)

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 (Aug 24, 2020)

efattah said:


> 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 (Aug 29, 2020)

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 (Aug 29, 2020)

Devagio said:


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


You already know the thread. GL.


----------



## TerryD (Aug 29, 2020)

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


----------



## Devagio (Aug 30, 2020)

TerryD said:


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


----------



## TheSlykrCubr (Oct 11, 2020)

thread needs to be continued, i think



how bout

fb

3/4 belt

last edge while placing DBR

L5CO

L5CP

L5E


----------



## trangium (Oct 20, 2020)

What if you did L5EP with the DR edge instead of the DF edge? That way you could have <R, U> L5EP algs instead of <M, U>, and 6CP algorithms would improve. I expected this to only be viable for one-handed, but many of the algs are so good that they outperform the <M, U> algs for even two-handed. Both P perms, both O perms, and the Qa perm are especially good compared to their respective <M, U> algs. Also consider that switching from <R2, U, D> turning to <M, U> turning requires a grip shift.

Here's a full list of L5EP algs with the DR edge unsolved.


Spoiler




CasePictureAlgNotesI
1/15




S' U2 SLeft index leaves the cube during U2. Use a left index push for S.Ua
1/15



R U R' U R' U' R2 U' R' U R' U RThis alg is relatively long but it flows well. To memorize, watch the pairs move around.Ub
1/15



R' U R' U' R3 U' R' U R U R2Start with the right thumb on top. The R3 is intentional and is done as a rolling R3. It's there to prevent a regrip.Pa
1/15



R U R' U' R' U' R' U RVery easy to memorize: Take out a pair, R', insert the pair. Make sure not to regrip after the third R'.Pb
1/15



R' U' R U R U R U' R'Mirror of Pa.H
1/60



M2 U M2 U2 M2 U M2Z
1/30



M2 U2 M U M2 U M2 U MCa
1/15



R U R' U R' U' R2 U' R' U2 R U R U' R'The first 9 moves are the same as the Ua perm. A long alg, but it flows well. Do the 3rd to last move as a rolled R.Cb
1/15



F2 U' r2 F2 R2 U' F2 r2This alg is hard to master but can be very fast. Start with right thumb on bottom to do F2. Make sure your left thumb is not in the way of doing an r2. The second F2 is done like a right hand D2.D
1/15



R U2 R2 U2 R2 U2 RWa
1/15



D' M' U2 M U M' U2 MThere is a 13-move <R, U> alg for the W perms, but it's slower than just doing D' then <M, U>.Wb
1/15



D' M' U2 M U' M' U2 MSame as Wa except for the U' instead of the U.Qa
1/15



R U R' U R' U' R' U' R2 U2 RThe first 6 moves are the same as the Ua perm. Make sure not to regrip after the third R'.Qb
1/15



R' U' R U' R U R U R2 U2 R'Mirror of Qa. The (U R U) is tricky: Do the first U as an OH flick and the second as a left index push. You can reset your right hand while doing the U2 to make the R' easier.Oa
1/15



R' U' R U' R U R U' R2 U2 RThe first 7 moves are the same as the Qb perm.Ob
1/15



R U R' U R' U' R' U R2 U2 R'The first 7 moves are the same as the Qa perm. Make sure not to regrip after the third R'.



Also, is Devagio still practicing this method? If so, what progress has he made?


----------



## L1meDaBestest (Oct 22, 2020)

Devagio said:


> The original post has been updated.
> 
> Since the major steps have been frozen, interested people can begin transitioning to the method via the beginner variation. Do let it be known if you’re trying it out, whether you intend to continue to the full version, etc; this will motivate others to try it out and subsequently the method will develop quicker.
> 
> For those who wish to promote it, you could make YouTube tutorials or talk to YouTubers about it; since the method is fairly straightforward, it shouldn’t be difficult for anyone to make a tutorial.


This method looks incredible and I would really like to see how good this can get with fast recognition speeds.

I’ll learn the full method because with only 200 algs and that predicted move count you have definitely sold me on this (also the other reasons).

I average 10 with CFOP for reference and when I learn the whole method I’ll start posting progress if you would be interested.

I’m so glad I saw this and I think it will be really fun!


----------



## abunickabhi (Oct 23, 2020)

This is an interesting Roux variant.

But if I were to modify Roux, I would go more towards the Waterman system, like the LMCF method.


----------



## Devagio (Oct 23, 2020)

trangium said:


> What if you did L5EP with the DR edge instead of the DF edge? That way you could have <R, U> L5EP algs instead of <M, U>, and 6CP algorithms would improve. I expected this to only be viable for one-handed, but many of the algs are so good that they outperform the <M, U> algs for even two-handed. Both P perms, both O perms, and the Qa perm are especially good compared to their respective <M, U> algs. Also consider that switching from <R2, U, D> turning to <M, U> turning requires a grip shift.
> 
> Here's a full list of L5EP algs with the DR edge unsolved.
> 
> ...


So I did consider this possibility back when I had very little experience with the method, but discarded it because
1. I thought maybe at the top level people would transition from L5EP to L5E (I don’t anymore, this was around when only the first page of this thread existed) so MU is much more natural.
2. I just feel MU EPLL are better than RU EPLL except U perm, and the L5EP MU algorithms were so good that I (possibly incorrectly) reasoned MU L5EP is better than RU L5EP.
Later on, I just went on practicing with the method to get faster times than actively thinking about developing it.
But now that you mention it, yes, one of the biggest pauses I have is going from RUD grip to MU grip, and if the RU L5EP is this amazing, it’s definitely worth looking into.
While I don’t think 6CP on average will get any better, but yes, the faster algs will get even faster. Plus there will not be any need of learning two L5EP sets (DF and DB) so that’s less algs and more importantly a much cleaner way to do things.

By the way, I’m cubing very little nowadays, but any amount of cubing I do, it is to get faster with this method. I currently average 16-19, very inconsistent because 6CO can be a pain if we don’t know the algs.

I personally will continue using the MU version of the method because I really don’t want to drill more algorithms for a few more months. Once the pandemic subsides a little (or schools get wise enough to not increase workload to “catch up” -_-) I’ll most likely shift.

To anyone using the method, I guess the RU L5EP looks objectively better, so give it a shot. If I ever get to finally making the full website for the method, I’ll most likely keep the final step RU gen if it gives more promising results, plus to help with OH of course.


L1meDaBestest said:


> This method looks incredible and I would really like to see how good this can get with fast recognition speeds.
> 
> I’ll learn the full method because with only 200 algs and that predicted move count you have definitely sold me on this (also the other reasons).
> 
> ...


Hey! Welcome aboard! We would all really appreciate sharing or any progress or ideas regarding the method, and it’s really cool that you’re considering trying it out. It most definitely is fun.
I’ve been getting quite a few emails and DMs regarding this off late, so I’m considering making a discord group to talk about the method, take help, share progress, let non-users join to see if it’s fun, etc. I imagine it wouldn’t be to hard to set it up so I’ll do it this weekend.


----------



## Devagio (Oct 24, 2020)

Devagio said:


> I’ve been getting quite a few emails and DMs regarding this off late, so I’m considering making a discord group to talk about the method, take help, share progress, let non-users join to see if it’s fun, etc. I imagine it wouldn’t be to hard to set it up so I’ll do it this weekend.


Click here to join the discord! 
Everyone is welcome, especially those who haven't gotten around to try the method out but are interested to explore something new.


----------



## L1meDaBestest (Oct 27, 2020)

Devagio said:


> Click here to join the discord!
> Everyone is welcome, especially those who haven't gotten around to try the method out but are interested to explore something new.


I think a Discord is a great idea! It will be very good for talking about the method/progress. 

Also I think the link you sent may have been temporary (I don’t really know how it works) because it doesn’t work and says that it has expired.


----------



## TheSlykrCubr (Oct 27, 2020)

L1meDaBestest said:


> I think a Discord is a great idea! It will be very good for talking about the method/progress.
> 
> Also I think the link you sent may have been temporary (I don’t really know how it works) because it doesn’t work and says that it has expired.




here's a permanent one 





Discord - A New Way to Chat with Friends & Communities


Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.




discord.gg


----------



## Nir1213 (Oct 27, 2020)

abunickabhi said:


> This is an interesting Roux variant.
> 
> But if I were to modify Roux, I would go more towards the Waterman system, like the LMCF method.


there is already wateroux but i dont think its good though so maybe modifying roux another way???


----------



## Andreas5204 (Oct 30, 2020)

Good news! Mehta now has a complete algorithm sheet, with visuals!
Created by Andreas5204 and Cuberstache, with help from Devagio.








Mehta Alg Sheet - V1


Introduction <a href="https://docs.google.com/spreadsheets/d/1qY8c-ypPAn-51pDQOYI-DzpyMPnPAri2qOTh3ZG1fjw/edit#gid=2087327765">Full Mehta Algorithm Sheet! (now outdated: see Mehta-OS Alg Sheet V2)</a> created by Andreas5204 and Cuberstache This sheet contains all algorithms for the Mehta method....




docs.google.com


----------



## Nir1213 (Oct 30, 2020)

Andreas5204 said:


> Good news! Mehta now has a complete algorithm sheet, with visuals!
> Created by Andreas5204 and Cuberstache, with help from Devagio.
> 
> 
> ...


where all the algs?
edit:nvm found them


----------



## Andreas5204 (Oct 30, 2020)

Nir1213 said:


> where all the algs?



You had me worried there...


----------



## Devagio (Oct 31, 2020)

Andreas5204 said:


> Good news! Mehta now has a complete algorithm sheet, with visuals!
> Created by Andreas5204 and Cuberstache, with help from Devagio.
> 
> 
> ...


So here there's a slightly updated beginners' version of the method which is easier to learn and in general faster to solve the cube with. I'll break it down here so it's easier to understand the beginners' section of the spread sheet.

1. FB
2a. Entire belt
2b. EO (algs in sheet)
3. 2-look 6CO
4. 2-look 6CP
5. 2-look L5EP

FB: Solve a 1x2x3 block in bottom left such that 6 of the stickers of the block are on the D face. You could just solve 3 cross pieces followed by two corners, but I'd recommend learn direct blockbuilding ASAP. Try to be CN from the start.
Belt: Solve the 4 E slice edges. Note, you have a free R layer, so you will not have to worry about restoring anything in general, so be efficient here.
EO: Orient the last 5 edges using one of the 5 algorithms in the sheet.
*6CO-1:* The only difficult-to-understand concept. The idea is to have DFR and DBR stickers to be the top/bottom colour. There are 4 cases. If there are two adjacent corners in the lop layer which are oriented, simply use R2 U2 R2 to put them in D layer and move to the next step. Else, there will always exist a pair of opposite corners in the top layer that are unoriented (this can happen in 3 ways: N, Z or L). Simply use the corresponding algorithm given in the sheet.
6CO-2: Basically OCLL but with better algs.
6CP-1: Use an R2 U R2 type insert to solve the DBR corner.
6CP-2: Solve all of the last 5 corners using one of 8 algorithms in the sheet. If DFR is solved, it is either J or Y perm, else the case is recognised by looking at the top layer corners in F face and R face.
L5EP-1: Solve the final D layer edge using an M' U2 M type insert.
L5EP-2: Basically EPLL but with potentially an ADF as well.

Will put an example solve in the example solves thread.



Spoiler: Stats



This beginner version for single FB averages well under 60 moves. Moreover, 7 out of the 9 steps are algorithmic, i.e. no scope of inefficiency there; hence even an inefficient solver with 3 - 3.5 TPS would be sub-20 theoretically.


----------



## Devagio (Nov 16, 2020)

With most of the development now happening on discord (in a greatly accelerated pace than here previously), I will give an update of the major developments for the benefit of those not on discord.

The general structure of the method is:
1. First block (FB)
2. 3-Quarters belt (3QB)
3. last edge + edge orientation (EOLE) [56 cases]
4. orienting 6 remaining corners (6CO) [72 cases]
5. permuting 6 remaining corners (6CP) [48 cases]
6. permuting 5 remaining edges (L5EP) [16 cases]

The first 3 steps are collectively called EO-ledge.

The recognition systems for 6CO and 6CP have been formulated.

There has been a great deal of emphasis on option select due to the algorithmic nature of the method. The three major options to finish the solve after EO-ledge are:

a. 6CO + 6CP + L5EP: The original default route which will be the most efficient 3-step path most of the times.

b. 6CO + DR bar + PLL: Sometimes it takes only 3-4 moves to make and insert the DFR and DBR corners, as well as the DR edge. There are about 40 cases for DR-bar the algorithms for which are already generated. If the 6CP is not great, or the DR bar is very obvious, we could do this instead and follow it up by one of 21 PLL cases. This is not ideal to use as default due to PLL algorithms being much worse in recognition and execution than L5EP algs, and some DR-bar algs being not great.

c. DFR-DBR + COLL + L5EP: Sometimes it may be much easier to solve the DFR and DBR corners (3-7 moves) instead of recognising and doing 6CO. This has ~100 algorithms, many of which are not great, but can be used if the 6CO case is not great or the D-corners solution is very obvious. This can be followed up with COLL leaving L5EP.

There are many other option select possibilities (most notably 6CO + edges + corners which is extremely efficient but almost never worth it recognition-wise) but the above seem more than sufficient to always have a great finish to the solve. There are some trick algorithms sets (like 4 corners only, setups to PLLs, etc.) which can pop up a couple times in an ao100 and potentially help us skip a step.

For L5EP, I personally believe it is best to learn it from right, front and back (4+ 12 x 3 short algs) to save a move on ADF at the end. The current consensus is if only one of the sets is to be learned, it has to be L5EP on right.

There are a lot of other developments (like the OH variation, the big-cube variation, the squan variation, Mehta-1LLL, etc) because they aren't as relevant here.

The current plan is to work on developing EO-ledge to make it more ergonomic and flexible.
Many of us have started getting good times with the method, and the example solves forum and reconstructions forum have progressively great solves with the method if you haven't checked them out yet.

So many people have combined efforts into developing, compiling and testing the above, that it would be extremely difficult for me to provide appropriate credit to everyone, which is why I highly encourage to check out their work on the discord server, where you will find all the algorithms (except DFR-DBR) and respective recog systems I mentioned above. 

If you'd like to contribute towards the method in any way, or consider using it, join the discord server using the link in one of the previous posts.


----------



## Devagio (Nov 19, 2020)

An example solve using "Meta-Mehta"

U' L' F2 D2 L2 F2 R2 U' B2 R2 L' B U B F2 L' F R2

y2 // inspection
M' B2 U' L B2 // FB+1e (5/5)
u' R U R u R2 // +2e (6/11)
F' U F2 R F' R' // EOLE (6/17)
R' U' R U' R' U2 R' U' R2 // DR-block (9/26)
R2 D R' U2 R D' R' U' R' U R U2 R' // ZBLL (13/39)
E' // ABF (1/40)

This is basically the ZB-equivalent of Mehta, where after EO-ledge, we solve the DR-block with 1 alg (2-gen 9-mover, ~400 cases), and end up with ZBLL (~500 cases). HARCS gives sub-40 movecount. Better names coming soon.

Also note the way EO-ledge is done - FB + 1 belt edge is planned in inspection, and the 3QB is completed by solving 2 more edges simultaneously (will have under 90 cases, so just like F2L this can be both intuitive and algorithmic). This will standardise FB+3QB enough for us to minimize usage of u moves and facilitate lookahead. This is still under experimentation though.


----------



## trangium (Nov 19, 2020)

Devagio said:


> An example solve using "Meta-Mehta"
> 
> U' R2 B2 R L' F' R2 L' D' B2 L' U2 R2 F2 D2 B2 R' D2 R
> 
> ...


The example solve doesn't work.
Click here to view on alg.cubing.net


----------



## Devagio (Nov 20, 2020)

trangium said:


> The example solve doesn't work.
> Click here to view on alg.cubing.net


Yeah, I had put an incorrect scramble by mistake. It works now.


----------



## LukasCubes (Nov 21, 2020)

this method seems kinda interesting lol


----------



## Nir1213 (Nov 22, 2020)

Devagio said:


> An example solve using "Meta-Mehta"
> 
> U' L' F2 D2 L2 F2 R2 U' B2 R2 L' B U B F2 L' F R2
> 
> ...


im curious, its sub-40 movecount?? Thats even lower than roux and zz, and is it still as/better than CFOP??? the ZB equivalent of metha might be one of the most fastest and/or efficient methods for speedsolving.


----------



## LukasCubes (Nov 22, 2020)

Devagio said:


> An example solve using "Meta-Mehta"
> 
> U' L' F2 D2 L2 F2 R2 U' B2 R2 L' B U B F2 L' F R2
> 
> ...


im gonna learn mehta-mehta or whatever this is called.

Edit: is there any youtube wideo or whatever this method is in?

Another edit: 37 moves. 9.25TPS to get a sub-4 on this solve. I average 3-4 TPS so this for me would probably be a sub-13 if I knew all this


----------



## LukasCubes (Nov 22, 2020)

Devagio said:


> Spoiler: Stats Simulation


is there a reconstruction of the 27 move solve? I wanna see it[/spoiler]


----------



## Andreas5204 (Nov 23, 2020)

Nir1213 said:


> im curious, its sub-40 movecount?? Thats even lower than roux and zz, and is it still as/better than CFOP??? the ZB equivalent of metha might be one of the most fastest and/or efficient methods for speedsolving.


HARCS says that Mehta-TDR (the new name of Meta-Mehta) is around 43 moves on average. You're right, it's a really promising top speedsolving method.


----------



## Andreas5204 (Nov 23, 2020)

Here is a link to a Reddit post about Mehta. It offers a full explanation, example solve, and links to helpful resources.
The response to that post was overwhelmingly (and unexpectedly) positive, and we had several new additions to our Discord server within the first day after posting.


----------



## Devagio (Nov 23, 2020)

Nir1213 said:


> im curious, its sub-40 movecount?? Thats even lower than roux and zz, and is it still as/better than CFOP??? the ZB equivalent of metha might be one of the most fastest and/or efficient methods for speedsolving.


HARCS with optimal TDR and ZBLL gives it 39.xy, and with the ZBLL alg-list and RUDS TDR gives around 43. Since a big chunk of this number is algs, real-life movecount would be very-close to 43, maybe even better if some advanced EOLedge is done. One of the most efficient, certainly. Fastest, I do put my bets on it and hope so but it's too soon to tell.


LukasCubes said:


> is there a reconstruction of the 27 move solve? I wanna see it[/spoiler]


I didn't save the simulation, but I ran the simulation again and again got (2) 27 move solutions. Remember, this is with a constrained version of the method (i.e. less efficient).
Here are the two solutions:

D2 B R' D B' R2 D , U R2 u R E2 R' u , U F R F' U R' , U2 L' U R2 U' R2 L , , ,

U2 R B L' F' D2 , E R' E2 R' u' , F R' F' R , U2 R U R2 U2 R2 U R' U2 R' U' R , , ,

Both were 6CP-skip and L5EP-skip.

EDIT: Ran a 200k solve simulation of the constrained version again, and got a 20-mover. EOLE-skip, 6CO-skip and L5EP-skip.
D L2 B' D F D2 L' B , U R' U E R u2 R u' , , , U2 R2 U' R2 , ,


----------



## Devagio (Nov 23, 2020)

I tried making a beginners' version tutorial. It's not great quality, but it's well explained and in depth.






Here is an overview of all variations of the method for 2H 3x3x3 after EO-ledge.


----------



## Swagrid (Nov 24, 2020)

Mehta-TDR (Meta-mehta) feels like one of those methods that will be hyped up before dying after nobody learns the algs, like ZB or ZZ-CT. Still excited to see it in practice though. Mehta and the variants are incredibly promising.


----------



## Jam88 (Nov 24, 2020)

Devagio said:


> I tried making a beginners' version tutorial. It's not great quality, but it's well explained and in depth.
> 
> 
> 
> ...


Where is the non- beginners method tutorial?
Because it seems interesting, but I don't understand the writing.


----------



## Andreas5204 (Nov 24, 2020)

Jam88 said:


> Where is the non- beginners method tutorial?
> Because it seems interesting, but I don't understand the writing.


The normal Mehta method is talked about in the second video Devagio linked.


----------



## Jam88 (Nov 24, 2020)

Andreas5204 said:


> The normal Mehta method is talked about in the second video Devagio linked.


OK thanks


----------



## Andreas5204 (Nov 24, 2020)

ZF slow said:


> Mehta-TDR (Meta-mehta) feels like one of those methods that will be hyped up before dying after nobody learns the algs, like ZB or ZZ-CT. Still excited to see it in practice though. Mehta and the variants are incredibly promising.


This may be the case, and of course it's too early to tell; but I don't think ZZ-CT is a fair comparison, since the algs are generally considered to be bad.
We'll be genning the TDR algs later this week. Once that's done, it'll be easier to compare Mehta-TDR and ZB.


----------



## Andreas5204 (Nov 29, 2020)

Some news from the Mehta server:
1. One of our members got an 8 second single, the fastest with Mehta so far, using...the beginner's method. This, we feel, is a really good indication that this method has a lot of potential.
2. We've been developing the TDR algs, with tons of help from @trangium. Once we have finalized a few things, we'll be able to make a proper Mehta-TDR to ZB comparison.
3. We have had lots of new members join our server in the past week, which is also really encouraging.


----------



## Silky (Nov 30, 2020)

Does anyone have an average movecount for the updated method ( not Meta-Mehta )?


----------



## Nir1213 (Nov 30, 2020)

this method could be used for speed fmc or something. @Cubing Forever what do you think?
mentioning so he could see this.


----------



## DNF_Cuber (Nov 30, 2020)

Nir1213 said:


> this method could be used for speed fmc or something. @Cubing Forever what do you think?
> mentioning so he could see this.


Spoiler:The popularity of speed FMC


Spoiler



It is barely even a weekly comp event


EDIT: I think this is a good speedsolving method but speed FMC isn't a worthwhile use


----------



## Devagio (Nov 30, 2020)

Silky said:


> Does anyone have an average movecount for the updated method ( not Meta-Mehta )?



This should answer your question. As for when you know more than 1 variation and use option-select, that'll probably have to wait till someone simulates it.


----------



## LukasCubes (Dec 1, 2020)

Can you do a solve simulation with a few thousand mehta TDR solves and give me the reconscruction of the lowest movecount? Also how do you do solve simulations?


----------



## Andreas5204 (Dec 1, 2020)

HARCS doesn't give individual reconstructions, just numbers.
HARCS give Mehta-TDR an average movecount of around 43, but that number is actually lower, because HARCS ran the simulations on fixed-FB and belt. A color neutral solver could realistically expect a lower movecount. @Devagio can post the HARCS stats.


----------



## Cubing Forever (Dec 1, 2020)

Nir1213 said:


> this method could be used for speed fmc or something. @Cubing Forever what do you think?
> mentioning so he could see this.


Yeah good point bc speed FMC doesn't allow the time to think a lot so this might be useful.
But anyone using this for normal FMC can achieve sub 30 consistently.
other than that, this could be a very fast method if used with full ZBLL
maybe this could beat CFOP and Roux in the near future.


----------



## Devagio (Dec 1, 2020)

Andreas5204 said:


> HARCS doesn't give individual reconstructions, just numbers.
> HARCS give Mehta-TDR an average movecount of around 43, but that number is actually lower, because HARCS ran the simulations on fixed-FB and belt. A color neutral solver could realistically expect a lower movecount. @Devagio can post the HARCS stats.


Actually HARCS can export reconstructions.




LukasCubes said:


> Can you do a solve simulation with a few thousand mehta TDR solves and give me the reconscruction of the lowest movecount? Also how do you do solve simulations?


I've attached a reconstruction of 100 solves. These wouldn't be great solves to emulate because HARCS doesn't utilise the D offset, has a single FB, and a fixed belt, leading to 3-4 extra moves on average. But you should get an idea.


----------



## Andreas5204 (Dec 1, 2020)

Devagio said:


> Actually HARCS can export reconstructions.


My bad, I did not know this.


----------



## Devagio (Dec 14, 2020)

Finally came round to write code for simulating solves with Mehta, accounting for everything that HARCS could not. Here are the results for a 1000 solve simulation -

Step Mean StD. Median Min Max 
FB (CN, unfixed): 5.158 0.730 5.0 2 7 
3QB (unfixed): 4.988 0.968 5.0 1 7 
EOLE (speed-optimal): 7.278 1.547 7.0 3 11 
Finish (speed-optimal): 26.274 3.321 27.0 15 35 
Total: 43.698 3.863 44.0 30 56

Out of 1000 solves, the shortest solutions were using: 
CDRLL: 446 
JTLE : 129 
6CP : 467 
APDR : 200

Here is the movecount histogram




The basic take-away is that the method averages ~43.7 moves; and with the intuitive portion of the solve being only 10.1 (which is the only place where humans will be inefficient compared to computers), the practical / human movecount average for speedsolves should be 45-46 moves at worst (assuming 20% inefficiency for intuitive steps). This keeps the method up there with Roux in terms of efficiency (said to be ~48 moves in human speedsolves), but with an algorithmic approach.

More detailed stats and the code are put up in discord. I will soon do a simulation for the TDR variation as well.


----------



## DNF_Cuber (Dec 14, 2020)

Have you thought about after 6CO, instead of permuting all the corners, you could just do the D layer ones, and then go into HKPLL? (or PLL+1 I think it's the same.) 
Just an idea.


----------



## Jam88 (Dec 14, 2020)

DNF_Cuber said:


> Have you thought about after 6CO, instead of permuting all the corners, you could just do the D layer ones, and then go into HKPLL? (or PLL+1 I think it's the same.)
> Just an idea.


Could make a nice variant


----------



## Devagio (Dec 14, 2020)

DNF_Cuber said:


> Have you thought about after 6CO, instead of permuting all the corners, you could just do the D layer ones, and then go into HKPLL? (or PLL+1 I think it's the same.)
> Just an idea.


We did consider HKPLL and TTLL variations, but compared to the sets currently in use these have pretty bad algorithms on average. What these could be useful for are as trick subsets. Basically, the solver learns the better algs in the algset. Then, for example if 2 of the 3 bottom pieces happen to be solved after 6CO (would happen about once every 10 solves), the solver would check to see if it is one of the case they know; if they do know it then they would in essence be skipping a step.


----------



## DNF_Cuber (Dec 14, 2020)

Devagio said:


> We did consider HKPLL and TTLL variations, but compared to the sets currently in use these have pretty bad algorithms on average. What these could be useful for are as trick subsets. Basically, the solver learns the better algs in the algset. Then, for example if 2 of the 3 bottom pieces happen to be solved after 6CO (would happen about once every 10 solves), the solver would check to see if it is one of the case they know; if they do know it then they would in essence be skipping a step.


Okay, I was just wondering if you had thought of it.


----------



## Devagio (Dec 21, 2020)

16000 Solves were simulated using each of the 4 paths individually. The entire data file and code is available on discord, here is the summary of the data.
Note, FB and 3QB are move-optimal CN solutions, and the rest is speed-optimal algorithms; thus the human move-count during a speedsolve would be 1-3 moves higher than the indicated values.









With full option-select (which is basically the theme of the method) the human move-count could very well average around 45 moves as indicated in one of the previous posts. For a high-TPS algorithmic method, this should be plenty to at least compete at the highest level.


----------



## Cubing Forever (Dec 21, 2020)

Devagio said:


> 16000 Solves were simulated using each of the 4 paths individually. The entire data file and code is available on discord, here is the summary of the data.
> Note, FB and 3QB are move-optimal CN solutions, and the rest is speed-optimal algorithms; thus the human move-count during a speedsolve would be 1-3 moves higher than the indicated values.
> 
> View attachment 14308
> ...


What about TDR?


----------



## Devagio (Dec 21, 2020)

Cubing Forever said:


> What about TDR?


It is not a part of the option-select variant, it is a method by itself. I will generate the statistics once the final algorithms are ready. Currently we are done with about 200/350 of the algorithms.


----------



## Spencer131 (Dec 21, 2020)

efattah said:


> The 'problem' with a 500 algorithm method isn't learning the algorithms-- it is spending the HUGE amount of time generating-testing-regenerating algorithms for each case.



Have you seen AlgExplorer? It doesn't always produce optimal solutions but this could be a good starting place.

Original post: https://www.speedsolving.com/thread...ine-utility-to-assist-in-alg-searching.65189/
Github: https://github.com/john-ml/AlgExplorer


----------



## err0r (Dec 28, 2020)

Here's my video tutorial for the beginners' variant of Mehta:





I also worked with Devagio and Andreas to design a logo for Mehta:


----------



## OreKehStrah (Dec 28, 2020)

err0r said:


> Here's my video tutorial for the beginners' variant of Mehta:
> 
> 
> 
> ...


The logo looks sick! Good job!


----------



## err0r (Dec 28, 2020)

OreKehStrah said:


> The logo looks sick! Good job!


Thanks!

I wonder if Mehta is the first method to have a logo
That would be cool


----------



## DNF_Cuber (Dec 28, 2020)

err0r said:


> Thanks!
> 
> I wonder if Mehta is the first method to have a logo
> That would be cool


well CFOP has the first cross, roux has Blocks+Corners, and ZZ has line and those are kinda like logos.


----------



## Devagio (Dec 30, 2020)

The Mehta Website is finally complete! This is meant to be a one-stop place for the method; it has EVERYTHING that there is to know about the method in one place including algs, stats, relevant links, etc. I've tried to make it as concise and user-friendly as possible.






Mehta


3x3x3 Speedsolving Method - Mehta




devagio.github.io


----------



## Silky (Dec 30, 2020)

Devagio said:


> The Mehta Website is finally complete! This is meant to be a one-stop place for the method; it has EVERYTHING that there is to know about the method in one place including algs, stats, relevant links, etc. I've tried to make it as concise and user-friendly as possible.
> 
> 
> 
> ...


Niiiice dude. Are you going to put up YruRU as well ?


----------



## Cubing Forever (Dec 30, 2020)

Devagio said:


> The Mehta Website is finally complete! This is meant to be a one-stop place for the method; it has EVERYTHING that there is to know about the method in one place including algs, stats, relevant links, etc. I've tried to make it as concise and user-friendly as possible.
> 
> 
> 
> ...


It's soooo cool 



Silky said:


> Niiiice dude. Are you going to put up YruRU as well ?


I think there's one already. I can't find it


----------



## Cuberstache (Dec 30, 2020)

Silky said:


> Niiiice dude. Are you going to put up YruRU as well ?








YruRU


One-handed speedsolving method YruRU



devagio.github.io


----------



## ProStar (Jan 14, 2021)

I'm finally taking an actual look at this method, and it looks really cool. However, I'm having trouble deciphering your alg organization system. Could someone please give an explanation of it?


----------



## Cuberstache (Jan 14, 2021)

ProStar said:


> I'm finally taking an actual look at this method, and it looks really cool. However, I'm having trouble deciphering your alg organization system. Could someone please give an explanation of it?


Check out the github page on OS: https://devagio.github.io/Mehta/mehta_os.html
The image on the front page is also helpful: https://devagio.github.io/Mehta/


----------



## Devagio (Jan 22, 2021)

Here is a leaderboard of the top averages and singles of users with Mehta.
To submit your times, join the discord and look for the announcement dated 21 January (or 22 January for Eastern countries).


----------



## RoundUpCubing (Jan 22, 2021)

ive been using mehta for a few hours now and its just so much fun! still trying to learn the 6cp cases because procrastination exists, just reading off the alg sheet atm. gonna see how much faster i can get with it, and might even replace cfop with it!


----------



## Jam88 (Jan 22, 2021)

Devagio said:


> Here is a leaderboard of the top averages and singles of users with Mehta.
> To submit your times, join the discord and look for the announcement dated 21 January (or 22 January for Eastern countries).


Finally a leaderboard I can get top 10 on! For how long though...


----------



## efattah (Jan 22, 2021)

Remind the leaders to submit their Ao5/Ao12 videos to the Uncommon Method competition thread so they can win a cash prize at the end of February.
The time to beat in that thread is currently 14.67 Ao12 and is clearly beaten by the top Mehta solvers thus far.


----------



## DNF_Cuber (Jan 22, 2021)

Can you add my 30.42 mehta single to the leaderboard? Or do you need a vid?


----------



## Jam88 (Jan 22, 2021)

DNF_Cuber said:


> Can you add my 30.42 mehta single to the leaderboard? Or do you need a vid?


He said ask on the discord in #progress-updates and @ mention @DIO and 2 others


----------



## BenChristman1 (Jan 23, 2021)

So I have a couple questions:

1. For the last couple days, I've been playing with the 6CO > APDR > PLL path. I'm basically using R2 <U> R2 setups to different CFOP CO cases, then intuitively doing APDR by putting 2 of the 3 pieces together, then either spamming R2 <U> R2 (if it's a corner) or doing M' U2 M / S' U2 S (if it's the edge) to insert the last piece. Pretty much my only goal is to get globally sub-30. Could I get sub-30 with this? If not, what more should I learn?

2. How many algs would it be to do CO > Solved? It might not be a feasible number, but it might be about the same as ZBLL? (I'm not doing any calculations or anything, so that might be really far off.)


----------



## Cubing Forever (Jan 23, 2021)

BenChristman1 said:


> So I have a couple questions:
> 
> 1. For the last couple days, I've been playing with the 6CO > APDR > PLL path. I'm basically using R2 <U> R2 setups to different CFOP CO cases, then intuitively doing APDR by putting 2 of the 3 pieces together, then either spamming R2 <U> R2 (if it's a corner) or doing M' U2 M / S' U2 S (if it's the edge) to insert the last piece. Pretty much my only goal is to get globally sub-30. Could I get sub-30 with this? If not, what more should I learn?


I've been doing the same thing for a few days now and it leads to faster times than 6CP. You can get sub 30 easily with what you're doing now.

Now for my question:

For the APDR cases where a 2x1 is solved on the bottom, should I start learning a few easy TTLLs or just stick to R2 U R2 U R2 U2 R2 and mirror for now?


----------



## Cuberstache (Jan 23, 2021)

Cubing Forever said:


> For the APDR cases where a 2x1 is solved on the bottom, should I start learning a few easy TTLLs or just stick to R2 U R2 U R2 U2 R2 and mirror for now?


You would be better off learning actual APDR and 6CO algs before learning niche cases that are extremely rare.


----------



## PiKeeper (Jan 27, 2021)

I'm just getting back into cubing and am sub-40 with CFOP 4LLL. Would it be useful to switch to Mehta now or to keep learning CFOP until I'm sub-20?


----------



## SH03L4C3 (Jan 27, 2021)

can one of yall make a vid on this meathod? I am not quite getting it


----------



## Jam88 (Jan 27, 2021)

Mathsoccer said:


> I'm just getting back into cubing and am sub-40 with CFOP 4LLL. Would it be useful to switch to Mehta now or to keep learning CFOP until I'm sub-20?


If you want to use it, switch as early as possible so you don't have really strong CFOP impulses.


SH03L4C3 said:


> can one of yall make a vid on this meathod? I am not quite getting it


There is one earlier in the thread, and the discord is very helpful!


----------



## Silky (Jan 29, 2021)

Just a quick question about 6CO. Why are there 71 cases instead of 53 used in SOAP? Does it have to with preserving edge pieces?


----------



## BenChristman1 (Jan 29, 2021)

Silky said:


> Just a quick question about 6CO. Why are there 71 cases instead of 53 used in SOAP? Does it have to with preserving edge pieces?


Yeah, I’m pretty sure it’s because you have to preserve the RF and RB edges.


----------



## carcass (Jan 30, 2021)

Mathsoccer said:


> I'm just getting back into cubing and am sub-40 with CFOP 4LLL. Would it be useful to switch to Mehta now or to keep learning CFOP until I'm sub-20?


I would love to see this method grow, unless you are itching to use cfop, i would recommend using it. I already know 2lll, and mehta is so much fun, but I don't know what to use it for because I am 2 years deep in cfop knowledge. Would mehta be good for OH?


----------



## Cuberstache (Jan 30, 2021)

carcass said:


> Would mehta be good for OH?


Probably better than CFOP but worse than ZZ or Roux. If you want to learn a method specifically for OH, try YruRU.


----------



## PetraPine (Jan 30, 2021)

CuberStache said:


> Probably better than CFOP but worse than ZZ or Roux. If you want to learn a method specifically for OH, try YruRU.


if you want to learn a method specifically for oh try
roux, its really really good for oh and alot easier to learn


----------



## carcass (Jan 30, 2021)

I know roux is ideal for OH, but I don't want to switch from cfop for 2H, and I don't want Mehta to not have a use in my cubing repertoire. Thanks for the suggestions!


----------



## Devagio (Feb 13, 2021)

Updates:
The TDR-V3 sheet is finally ready! This sheet contains all the speed-optimal TDR algs first narrowed down to 5-7 for each case using MCC, then handpicked by drilling them all in person by the Mehta staff over the past months. 
Once this was done, simulation of 250k solves was run and the stats have been updated on the Mehta github website. This website is the best resource to learn about and understand the method, and as of this moment is an exhaustive resource containing all variations, algorithms, statistics, relevant links, etc. 
We have had a massive influx of speedcubers on the discord, including some world-class solvers trying out the method.
Also, the method was first proposed around 13-14 August 2020, which makes this roughly its half year anniversary!


----------



## Deleted member 55877 (Feb 24, 2021)

i just learned mehta! i will use it for a couple weeks to test its potential


----------



## Cubing Forever (Feb 24, 2021)

I'm experimenting with a 2x2x3->3QB approach and I think it's more efficient than full CN tbh.


----------



## Cuberstache (Feb 25, 2021)

Cubing Forever said:


> I'm experimenting with a 2x2x3->3QB approach and I think it's more efficient than full CN tbh.


It's probably a move or two worse if you do optimal FB but that can definitely be pretty difficult.


----------



## Devagio (Sep 23, 2021)

Hey all!
It’s been a while on this thread since most of the developments have been happening in the discord. If you’re interested in how things have progressed, feel free to join the server with the invite like somewhere on this thread.
The main purpose of making this post was to showcase this amazing video by @Cuberstache.
Also maybe have a look at this commentary by @ottozing.
Happy cubing!


----------



## Filipe Teixeira (Oct 24, 2021)

https://speedcubedb.com/a/3x3/TDR

tdr algs on speedcube.db


----------



## Cuberstache (Oct 24, 2021)

Filipe Teixeira said:


> https://speedcubedb.com/a/3x3/TDR
> 
> tdr algs on speedcube.db


More like TDR images lol, the algs have yet to be added.


----------



## Cubing Forever (Dec 14, 2021)

Post in thread 'The New Method / Substep / Concept Idea Thread' https://www.speedsolving.com/threads/the-new-method-substep-concept-idea-thread.40975/post-1464663

I guess I'll link this here since it's a Mehta variant.


----------



## Devagio (Dec 16, 2021)

Cubing Forever said:


> Post in thread 'The New Method / Substep / Concept Idea Thread' https://www.speedsolving.com/threads/the-new-method-substep-concept-idea-thread.40975/post-1464663
> 
> I guess I'll link this here since it's a Mehta variant.


Cool idea.
The current algs can definitely be drastically be improved, and there’ll be fewer than 25 cases; you’re double counting some of them.
I’m very skeptical of the recognition, it’s worth considering only if there’s even a remotely acceptable recog system.


----------



## OreKehStrah (Dec 16, 2021)

Devagio said:


> Cool idea.
> The current algs can definitely be drastically be improved, and there’ll be fewer than 25 cases; you’re double counting some of them.
> I’m very skeptical of the recognition, it’s worth considering only if there’s even a remotely acceptable recog system.


Recog is quite easy. You just would recognize the COLL case, and know which CP that COLL corresponds to, and recognize the EO case, which should be pretty straightforward as well.


----------



## Devagio (Dec 16, 2021)

OreKehStrah said:


> Recog is quite easy. You just would recognize the COLL case, and know which CP that COLL corresponds to, and recognize the EO case, which should be pretty straightforward as well.


Oh right, I missed that we need to do DCAL before CPEO. Also explains the long algorithms. 
In this case, my question becomes - ‘How does this provide any benefits over the CDRLL variation?’
CDRLL has a more standard recognition than CPEO and better algs; and L5EP is arguably better than 2GLL in almost all aspects. This also has more algs and cannot fit well into the OS system. Also CDRLL leads more naturally to TDR which is objectively superior for OH solving.


----------



## OreKehStrah (Dec 16, 2021)

Devagio said:


> Oh right, I missed that we need to do DCAL before CPEO. Also explains the long algorithms.
> In this case, my question becomes - ‘How does this provide any benefits over the CDRLL variation?’
> CDRLL has a more standard recognition than CPEO and better algs; and L5EP is arguably better than 2GLL in almost all aspects. This also has more algs and cannot fit well into the OS system. Also CDRLL leads more naturally to TDR which is objectively superior for OH solving.


I agree


----------



## Cubing Forever (Dec 18, 2021)

Devagio said:


> L5EP is arguably better than 2GLL in almost all aspects.


The 2GLL+1 variant actually solves 2GLL+DR edge(basically CDRLL+L5EP in 1 alg).
Isn't a 1-alg system better than a 2-alg system?



Devagio said:


> This also has more algs and cannot fit well into the OS system.


I wanted it to be a variant of its own though, like TDR. Although you can do regular CDRLL/JTLE OS if you find all your edges oriented at the end of DCAL.



Devagio said:


> and there’ll be fewer than 25 cases


Umm yeah but its just one less. There's 12 cases for DR oriented(3 line+6 L+3 dot) and 12 more(6 arrow+6 1/1) for DR misoriented) which equals 24?



Devagio said:


> ‘How does this provide any benefits over the CDRLL variation?’


A nicer, 2 gen finish and the absence of EOLE?(which imo isn't that great for OH(yeah, I tried genning algs for it, they weren't that great)



Devagio said:


> The current algs can definitely be drastically be improved,


I agree.

On a sidenote, my Mehta OH OS algsheet v1 is complete. You can comment to suggest better algs.


----------



## Burrito (Mar 18, 2022)

Best Mehta Path?
I know full PLL if it helps


----------



## OreKehStrah (Mar 18, 2022)

GenZ Cubing said:


> If this is the wrong place sorry
> I know full PLL if it helps


The best path for is not using Mehta since it’s worse Petrus


----------



## GenTheThief (Mar 18, 2022)

As far as I know, mehta-dtr is the best variant, although in this case, "best" isn't saying much.


----------



## Timona (Mar 18, 2022)

Why is everyone hating on Mehta lol


----------



## DuckubingCuber347 (Mar 18, 2022)

4ce7heGuy said:


> Why is everyone hating on Mehta lol


Because APB finally snapped everybody out of a trance, and they all finally understood it has bad ergonomics.


----------



## Swagrid (Mar 18, 2022)

4ce7heGuy said:


> Why is everyone hating on Mehta lol


Petrus but with 400 more algs and a few more moves


----------



## Swagrid (Mar 18, 2022)

GenZ Cubing said:


> People who know about Mehta should comment here, @Swagrid


I am quite familiar with Mehta, I was onboard with it back in the day. But not anymore.


----------



## OreKehStrah (Mar 19, 2022)

GenZ Cubing said:


> People who know about Mehta should comment here, @Swagrid


Bruh aren’t you the one asking what is the best version of Mehta? Sounds like you don’t know what you’re talking about either


----------



## Jack Reiman (Mar 19, 2022)

GenZ Cubing said:


> People who know about Mehta should comment here, @Swagrid


Hi, I used mehta for about 5 months and used the cdrll variant. Swagrid is right. Thank you.


----------



## PapaSmurf (Mar 19, 2022)

*claps*


----------



## Burrito (Mar 19, 2022)

Swagrid said:


> I am quite familiar with Mehta, I was onboard with it back in the day. But not anymore.


It doesn’t have 400 algs tho.

APDR sounds good, but there are lots of bad cases.
Same with JTLE.


----------



## Swagrid (Mar 19, 2022)

GenZ Cubing said:


> It doesn’t have 400 algs tho.


400 more than Petrus does, when using TDR. because EOLE is 50, and TDR 350. And we use TDR to compare because the toss-up for optimal Mehta is either TDR or OS, and since OS is so vague and varies from solver to solver, it can't be easily quantified. So TDR is the way to go for method comparison, and when compared to Petrus, it has 400 extra algs.


----------



## Silky (Mar 19, 2022)

Almost 20,000 views!


----------



## Jack Reiman (Mar 19, 2022)

GenZ Cubing said:


> It doesn’t have 400 algs tho.
> 
> APDR sounds good, but there are lots of bad cases.
> Same with JTLE.


real answer time:

do petrus or apb if you want a good method that's similar, but if you're dead set on using mehta use the 6co/separation variant.


----------



## Zeke_beke (Mar 30, 2022)

Mehta will never beat cfop


----------



## Timona (Mar 31, 2022)

Zeke_beke said:


> Mehta will never beat cfop


Bold statement, but never say never


----------



## cuberswoop (Mar 31, 2022)

Zeke_beke said:


> Mehta will never beat cfop


But CFOP will never beat Petrus.


----------



## Burrito (Nov 27, 2022)

Burrito said:


> It doesn’t have 400 algs tho.
> 
> APDR sounds good, but there are lots of bad cases.
> Same with JTLE.


i was so cringe back in the day lmao


----------

