CFOP-Breaker? Mehta method

[Devagio]

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.

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]

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

 

[trangium]

Intermediate version:
Step 1: FB (~6 moves)
Step 2: EO-Belt (~16 moves) <r,R,U>
Step 3: 6COLL (~13 moves) <R,U>
Step 4: 6CPLL (~12 moves) <R,U,D>
Step 5: L5EP (~13 moves) <M,U>
Avg ~ 60 moves

Advanced version:
Step 1: FB (~6 moves)
Step 2: Belt (~9 moves) <r,R,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

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]

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]

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]

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]

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]

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]

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

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]

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.

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]

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]

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]

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!

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.

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]

is this a good method

 

[TheSlykrCubr]

what's the +1

 

[TheSlykrCubr]

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

 

[I'm A Cuber]

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

Skip case

 

[TheSlykrCubr]

oh yeah

 

[Devagio]

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

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.