CFOP-Breaker? Mehta method

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.

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.

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


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.
 
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
 
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:
DF Loc.DB Loc.CaseAUFAlgAUFAlt AlgAUFAlt Alg
56SolvedD'
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' R2
DiagonalR 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 D2
Double 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 D2
Front BarD' R2 U R2 U' R2 D R2 D'D' R U R' U R2 D R D' R
Right 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 D2
Front 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' R
Double 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 R2
52Front OppD' R2 U2 R2 U' R2 U' R2U2D' R2 U R2 U R2 U2 R2 U2
Right 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' R2
Front 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' R2
Right OppU'R2 U F U F' R2 F U' F' D'R D' R' D R' U D' R2 U' R D R' D' R2
Double OppUR2 U D' R2 U R2 U' R2UR2 B2 U B2 D' R2
Front BarUR U2 R' D' R' D R' D' R' U2 R'U'R2 U R2 U R2 D' R2 U R2 U' R2
Right 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 R
2=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' R2
321=2, 3 AdjU2D' R U' R U R' D R D' R' U R2 U2 R2
1=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' R2
2=3, 1 OppF2 D' r2 D r U' r F2 r' U rUR2 U R2 U' R2 U2 D' R2 U R2 U' R2
All 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' R2
131=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 D2
2=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 R2
All 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
 
Last edited:
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:
DF Loc.DB Loc.CaseAUFAlgAUFAlt AlgAUFAlt Alg
56SolvedD'
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' RR' U R' F' R U R' U' R' F R2 U' R' U' R2
AdjacentR U R' D' R U' D2 R' U' R D2 R'R2 U R2 U2 R2 D' R2 U R2 U' R2
DiagonalR U' R' U R' U2 R2 U R U R' U' R2
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 D2
Double 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 D2
Front BarD' R2 U R2 U' R2 D R2 D'D' R U R' U R2 D R D' R
Right 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 D2
Front 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' R
Double 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 R2
52Front OppD' R2 U2 R2 U' R2 U' R2U2D' R2 U R2 U R2 U2 R2 U2
Right 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' R2
Front BarU2R2 D R2 U' R2 U R2 D2U2D R D' R D R2 U' R' U R D2
Right BarU'D R2 U' R2 U R2 D' R2 D'U'D R' U' R U R2 D' R' D R' D2
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' R2
Right OppU'R2 U F U F' R2 F U' F' D'R D' R' D R' U D' R2 U' R D R' D' R2
Double OppUR2 U D' R2 U R2 U' R2UR2 B2 U B2 D' R2
Front BarUR U2 R' D' R' D R' D' R' U2 R'U'R2 U R2 U R2 D' R2 U R2 U' R2
Right 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 R
2=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' R2
321=2, 3 AdjU2D' R U' R U R' D R D' R' U R2 U2 R2
1=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' R2
2=3, 1 OppF2 D' r2 D r U' r F2 r' U rUR2 U R2 U' R2 U2 D' R2 U R2 U' R2
All 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' R2
131=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 D2
2=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 R2
All 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
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.
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 :D
 
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.
 
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.
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.
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.
 
Last edited:
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!
 
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
 
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.
 
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
 
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.

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.

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.

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