• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 35,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

CFOP-Breaker? Mehta method

efattah

Member
Joined
Feb 14, 2016
Messages
573
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

Member
Joined
Aug 13, 2020
Messages
644
Location
37.8270° N, 122.4230° W
YouTube
Visit Channel
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

Member
Joined
Apr 21, 2020
Messages
220
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.
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.
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

Member
Joined
Jun 23, 2020
Messages
40
Location
the center of the USA
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

Member
Joined
Feb 14, 2016
Messages
573
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.
 
  • Like
Reactions: ep2

Devagio

Member
Joined
Apr 21, 2020
Messages
220
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.

DD
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 R
SuneR U R2 U' R2 U R
AntisuneR 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'
Onil
avg
6.63​
RR
HR 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' D
AntisuneR' U R D U R' U2 R D'
UR U' R2 U' R U2 R2 U' R
TR 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'
avg
9.13​
FB
HR U R' U' R2 U R2 U' R2 U2 R' U' R'R' U' R U R2 U' R2 U R2 U2 R U R
PiR U R2 U2 R2 U R' U2 R' U' R
SuneD' 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 R
UR' U2 R2 U' R2 U' R2 U2 R'
TR U2 R U2 R U2 R U2 R
LR' U R U R2 U' R2 U R' U2 R
OR2 U' R D' R U2 R' D RR U2 R U' R' U2 R U' R' U2 R'
avg
9.75​
RD
handL' U R2 U' R2 L R' D' R U' R' D R
asiaR 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 R
dogR 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 R
eagleR' U2 R U R2 U' R U2 R
avg
7.75​
FD
legR D' R U R' D R'
americaD R' U R U R' U2 R D' R2 U' R U2 R' U' R U' R
NR 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'
avg
8.13​
DR
legL U' R2 U R2 L' R D R' U' R D' R'
americaR' U R U R' U2 R
ND' R U2 R' U R U R' D
bR 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'
avg
7.75​
DB
handR' D R' U' R D' R
asiaR2 U2 R' U R' U R U2 R'
S R' U2 R U' R' U' R
p R' S' U2 S R'R' U' R U2 R' U' R
dogD' R U' R' U2 R U' R' DR' U R U R' U' R U R' U2 R
hammerF 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' R
avg
8.13​
FR
handR 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' D
dogR 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'
avg
9.5​
RB
legR' U R' U R U2 R
americaR2 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' R
sickleR U2 R U R2 U' R U2 R'R' U2 R U' R2 U R U2 R
fanR U' R' U R' U R' U' R
pigeonR' U2 R U' R2 U2 R2 U2 R' U' R
avg
9.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.

GG
GGGGR 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' R2
BBGGU2 F R' F' R2 U R'
BBBBU S' U S R U2 R'U R' F R2 F2 U2 F R'
avg
5.25​
GB
GGGBU2 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'
avg
6.125​
BG
GGGBF R F' R'
GGBGF R' F' R
GBGGR 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
avg
5.875​
BB
GGGGU' F' U FE R' U' R
GGBBF' U F2 R F' R'U R F R' F2 U' F
GBGBU2 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 F
BBBBU S' U S u' R' U' R
avg
5.625​
solved
0Bnil
1BR' 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 R2
avg
4.17​
flipped
0BF 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' R
2B (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' F
avg
7.17​
G
0BR' U' R U R
1BR 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 R
4BF R' F' R2 U2 F R' F'
avg
6.00​
B
0BF u' R u F2
1BF 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' R
4Bu' F R' F' U2 R F R2 F' R
avg
6.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.

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.
 

Sion

Member
Joined
Dec 13, 2015
Messages
970
Location
New York
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.

DD
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 R
SuneR U R2 U' R2 U R
AntisuneR 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'
Onil
avg
6.63​
RR
HR 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' D
AntisuneR' U R D U R' U2 R D'
UR U' R2 U' R U2 R2 U' R
TR 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'
avg
9.13​
FB
HR U R' U' R2 U R2 U' R2 U2 R' U' R'R' U' R U R2 U' R2 U R2 U2 R U R
PiR U R2 U2 R2 U R' U2 R' U' R
SuneD' 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 R
UR' U2 R2 U' R2 U' R2 U2 R'
TR U2 R U2 R U2 R U2 R
LR' U R U R2 U' R2 U R' U2 R
OR2 U' R D' R U2 R' D RR U2 R U' R' U2 R U' R' U2 R'
avg
9.75​
RD
handL' U R2 U' R2 LR' D' R U' R' D R
asiaR U' R' U' R U2 R'
SD R' U2 R U' R' U' R D'
pR' U R U2 R2 U' R U2 R
dogR 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 R
eagleR' U2 R U R2 U' R U2 R
avg
7.75​
FD
legR D' R U R' D R'
americaD R' U R U R' U2 R D'R2 U' R U2 R' U' R U' R
NR 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'
avg
8.13​
DR
legL U' R2 U R2 L'R D R' U' R D' R'
americaR' U R U R' U2 R
ND' R U2 R' U R U R' D
bR 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'
avg
7.75​
DB
handR' D R' U' R D' R
asiaR2 U2 R' U R' U R U2 R'
SR' U2 R U' R' U' R
pR' S' U2 S R'R' U' R U2 R' U' R
dogD' R U' R' U2 R U' R' DR' U R U R' U' R U R' U2 R
hammerF 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' R
avg
8.13​
FR
handR 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 R R U2 R' D' U R U R' D
dogR 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'
avg
9.5​
RB
legR' U R' U R U2 R
americaR2 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' R
sickleR U2 R U R2 U' R U2 R'R' U2 R U' R2 U R U2 R
fanR U' R' U R' U R' U' R
pigeonR' U2 R U' R2 U2 R2 U2 R' U' R
avg
9.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.

GG
GGGGR 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' R2
BBGGU2 F R' F' R2 U R'
BBBBU S' U S R U2 R'U R' F R2 F2 U2 F R'
avg
5.25​
GB
GGGBU2 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'
avg
6.125​
BG
GGGBF R F' R'
GGBGF R' F' R
GBGGR U R' F' U' FF 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
avg
5.875​
BB
GGGGU' F' U FE R' U' R
GGBBF' U F2 R F' R'U R F R' F2 U' F
GBGBU2 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 F
BBBBU S' U S u' R' U' R
avg
5.625​
solved
0Bnil
1BR' 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 R2
avg
4.17​
flipped
0BF 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' R
2B (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' F
avg
7.17​
G
0BR' U' R U R
1BR 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 R
4BF R' F' R2 U2 F R' F'
avg
6.00​
B
0BF u' R u F2
1BF 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' R
4Bu' F R' F' U2 R F R2 F' R
avg
6.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.

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.

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

Devagio

Member
Joined
Apr 21, 2020
Messages
220
1597778730185.png

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.


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 :(
 
Last edited:

mukerflap

Member
Joined
Jan 12, 2020
Messages
263
View attachment 13265

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.



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 :(
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
 

Devagio

Member
Joined
Apr 21, 2020
Messages
220
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.


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 R
SuneR U R2 U' R2 U R
AntisuneR 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'
Or use regular OCLL algs.

Location of DFR cornerCaseMain algAlt alg
DFRsolvedD'
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 D2
UBLdiagonalU2 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' R
UBLheadlights 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'

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

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.

I definitely don’t believe this.
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.
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.
 
Last edited:

zzcuberman

Member
Joined
Jul 27, 2020
Messages
84
personally i think this is a good method, but the double turns in the cp step really hinder it for me.
 

Devagio

Member
Joined
Apr 21, 2020
Messages
220
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

Member
Joined
Jul 27, 2020
Messages
84
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

Member
Joined
Jul 24, 2019
Messages
52
WCA
2019TRAN10
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.
 
Last edited:

Devagio

Member
Joined
Apr 21, 2020
Messages
220
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.
 
Top