The New Method / Substep / Concept Idea Thread

[Neuro]

This is exactly what we do in LMCF L5E if you see my document and there are only 8 cases (or 32 with reflections). And recognition is insanely easy.

Great to hear, I'll take a look at the cases!

So yeah you can get some crazy low LSE movecounts using this, I'll do like 10 or so solves and get back

https://alg.cubing.net/?setup=M2_U-...U-_M-_U-_M2&alg=U_M_U-_M_U_M2_U_M_U2_M-_U2_M-

https://alg.cubing.net/?setup=M-_U2...M2_U_M_U-_M-&alg=U_M2_U-_M-_U-_M_U-_M-_U-_M2

https://alg.cubing.net/?setup=M2_U_...-_U_M-&alg=U-_M_U-_M-_U_M-_U2_M-_U_M_U2_M2_U

So I did my tests with it and applied a 0.05 critical value (2 tailed) and the average movecount should be between 17 moves and 9 (yeah, pretty crazy range there I know.) Some of my cases probably could've been solved more efficiently, but these should still give pretty accurate results.

I've gotten 10-11 move LSE's using this, and the highest I got was a 14, which is the currently accepted average movecount for LSE.

I'd be willing to say that it is usually more efficient than normal LSE. Roux users, rejoice; you have yet another tool to add to your LSE arsenal!

 

[Teoidus]

Hm. Seems interesting. What was the average movecount?

 

[MethodNeutral]

This is exactly what we do in LMCF L5E if you see my document and there are only 8 cases (or 32 with reflections). And recognition is insanely easy.

Where can I see this document? I'd like to learn these if there are only 8 cases.

 

[Neuro]

Where can I see this document? I'd like to learn these if there are only 8 cases.

This has a doc with LMCF algs

Sorry here is version 4 with some corrections and additions.

With this formally compiled the average movecount for E2L algorithms is 6.15. In real solving there is usually 1.5 setup moves so the real average is 7.65.

Hm. Seems interesting. What was the average movecount?

Average movecount from my 10 examples was 13, but again some of the cases could've been done more efficiently (I'm not a Roux user, I just like to play with it from time to time) Also got some nasty cases that the LMCF algs couldn't do directly (based off of orientation of last LR edge in the buffer) so I had to work around that

 

[efattah]

LMCF has L5E algorithms for every possible case including bad and special cases. I'll update the document to add them all. Indeed there are special cases for many of the earlier steps as well.

 

[Shiv3r]

Seems interesting, but I think it would be more useful in special cases where one edge is pre-solved.
In fact, you could get even lower movecounts by inserting any U-layer edge, then inserting the other while doing EO, then doing 4C with UFUB sometimes.
Im going to try this out!

 

[efattah]

LMCF L5E can be expanded to L6E, I have been working on this for a few weeks now but I still haven't memorized all the cases. I am finishing generating the last cases and this method is extremely powerful both for LMCF and for Roux. In LMCF L6E, you solve the last 6 edges in 2 looks even if the L/R faces are misaligned (which happens in LMCF, but not in Roux). There are cases for all combinations of random solvings of the UR and UL edge (i.e. neither solved, one solved but disoriented, two solved but disoriented, etc.) In other words any MU scramble can be solved in 2-looks. The number of setup moves is 0-3 with an estimated average of 1; the average moves to solve UL+UR while orienting the midges is so far 8.3 (will have an exact number soon), and that leaves midge permutation which I assume has an average of 3.7 (if you include skips in the average). So the average move count would be 13.0 by my estimates, with one fewer looks than with Roux. Personally I am very skeptical of the 14 move count average of Roux LSE; by my own experiments it is more like 15-16, with 3 looks.

There are 110 cases if you include all the reflections. The average move count does not increase over L5E which is remarkable since you are solving an extra edge. For LMCF this is huge, because it keeps the L5E time the same but decreases the number of edges that need to be solved in the E2L phase from 7 down to 6, reducing the move count of LMCF by 3 moves from 44 to 41, and that still doesn't include Waterman's last step which drops the average by at least 1-2 more moves. So full LMCF (EGW) would theoretically have a 39-40 average if you use the advanced L6E.

I firmly believe this approach to the last six edges is faster than classic Roux LSE, so in the spirit that there may be more people interested in it for the Roux application vs. the small number of people interested in LMCF, I am compiling a more clear graphical document with all the cases clearly laid out. I should have it done in less than a week.

I would also comment that the move count is not entirely the whole story. Some cases are very unique and have finger tricks that are faster than most MU algorithms:

UL and UR both solved but disoriented, with 4 disoriented midges:
R' F R U M' U2 M2 U R' F' (+optional R) [10-11]
(this is 6 bad edges and would take 11 moves with Roux JUST TO ORIENT THE EDGES then you still have to solve UL/UR)

Solve DF into UR, with UL empty, UR holds the UL piece, oriented, with top midge orientations X O X:
L' U R B' M' B R' U' (+optional R) [8-9] -> extremely fast!

 

[Shiv3r]

UL and UR both solved but disoriented, with 4 disoriented midges:
R' F R U M' U2 M2 U R' F' (+optional R) [10-11]
(this is 6 bad edges and would take 11 moves with Roux JUST TO ORIENT THE EDGES then you still have to solve UL/UR)

not if you use advanced 6flip tricks(there are a few, where you solve the 6flip with misoriented centerw or whatnot). With the way I would execute that algorithm the movecount is actually just around that, like 10-11.

 

[Teoidus]

Personally I am very skeptical of the 14 move count average of Roux LSE; by my own experiments it is more like 15-16, with 3 looks.

If you use EOLR, it should be around 13. You can look up reconstructions of Lau's solves (though he doesn't actually make full use of EOLR) or reconstruct some of Kian's solves if you're curious.

I also think your 2-look system (orient + solve l/redge, then permute midges) is basically full EOLR -> 4c, which I think people are already doing. The difference is you've decided to generate non<M,U> algorithms.

For LMCF this is huge, because it keeps the L5E time the same but decreases the number of edges that need to be solved in the E2L phase from 7 down to 6, reducing the move count of LMCF by 3 moves from 44 to 41, and that still doesn't include Waterman's last step which drops the average by at least 1-2 more moves. So full LMCF (EGW) would theoretically have a 39-40 average if you use the advanced L6E.

I'm still not sure where you're getting these figures. 13 EG + 3 * 7 E2L + 13 LSE = 47 STM?

Unless you can ensure that P(skip >= 1 E2L pair + easy LSE case) is always 1, you're not going to be getting 39-40 STM movecounts?

 

[Teoidus]

34 STM 2GR

D B D B2 D R U L F2 D2 F' L2 B U' F' L2 B L' U' L2
x' // insp
y' E R B' r' U M2 // EOPair 6/6
y U L' U' L // CPLine 4/10
r2 U' R2' U' M2 U2 R' u2 // Block 8/18
U R' U2 R U R2' // F2L 6/24
M2 U M2 U M' U2 M2 U2 M' U // 2GLL 11/35

 

[efattah]

I also think your 2-look system (orient + solve l/redge, then permute midges) is basically full EOLR -> 4c, which I think people are already doing. The difference is you've decided to generate non<M,U> algorithms.
I'm still not sure where you're getting these figures. 13 EG + 3 * 7 E2L + 13 LSE = 47 STM?
Unless you can ensure that P(skip >= 1 E2L pair + easy LSE case) is always 1, you're not going to be getting 39-40 STM movecounts?

Answers:
1. The 2-look system may not have significantly fewer moves than Roux EOLR, but it will have faster TPS since you execute at algorithm speed instead of intuitive speed.

2. The move count for LMCF is more complicated than that:

You solve the centers and 1 edge in 1-2 moves on most solves, or sometimes it takes 3 moves after EG is finished
This leaves 5 edges left to solve. 50% of the time one of these is already solved, leaving two E2L pairs (2 x Z). The other 50% of the time you can solve the 5 edges as one pair (Z) and one triplet (7).

Things are further complicated by the number of moves Z required to solve a pair and triplet. A triplet will average about 7, and whereas the average movecount for the E2L pair algorithms is 6.3 + setup, that is not the actual average. That is the flat average across all the cases but it ignores the fact that the most common cases are 3 and 5 moves respectively. So the actual average for a pair will be less than the flat average across all the algorithms. Regardless, being extremely generous and using a value of 7 moves for both the pairs and triplets:

EG is 13
1 edge + center is solved in 1-3 moves
Then 14 moves for the remaining 5 edges
LSE is 13

So the predicted total is 13 + (1-3) + 14 + 13 = 41-43

However this does not take into account the high frequency where 2 or even 3 edges are pre-solved after doing the corners. In this case you get dramatically lower move counts (circa 35), and these bring down the average even more.

 

[Teoidus]

Answers:
1. The 2-look system may not have significantly fewer moves than Roux EOLR, but it will have faster TPS since you execute at algorithm speed instead of intuitive speed.

I don't think the idea of "intuitive speed" is useful. LSE feels very algorithmic to me at this point, even though I learned it intuitively. While I've seen you dismiss roux LSE as requiring too much thought many times, I have to disagree with the idea that Roux tps can't match your 2look system's tps. Movecount is comparable and Roux with constant lookahead, even at a slightly lower tps, will arguably beat maxed out tps + a delay to recognize.

2. The move count for LMCF is more complicated than that:

You solve the centers and 1 edge in 1-2 moves on most solves, or sometimes it takes 3 moves after EG is finished
This leaves 5 edges left to solve. 50% of the time one of these is already solved, leaving two E2L pairs (2 x Z). The other 50% of the time you can solve the 5 edges as one pair (Z) and one triplet (7).

Wasn't this triplet stuff a lucky thing? I see the point about the distributions being non-uniform, but I don't see how you can guarantee 2 looks/14 moves for E2L. Even in your example solves that you've posted you regularly seem to take more than this?

 

[efattah]

OK I just did a bunch of high speed solves (as fast as I could count) keeping lookahead realistic and not looking for 'optimal' cases, to see how many moves E2L takes to solve 6 edges:

15,19,19,18,14,17,25,15,15,21,14,21,12,12,19,18,25,20,16,19,16,21,25,23,15,15,15,16

The average was 17.85.

So EG (13) + E2L (17.85) + 2-look LSE (13) = 43.85

 

[efattah]

As far as Roux LSE and its advanced variants, it may be there is not a much better solution for Roux solvers. I can't use Roux LSE for LMCF anyway, so I'm just happily trying to improve my method with the 2-look LSE that works with disoriented L/R faces; if it has no value for other methods that is too bad but I'm mostly focused on improving my own method anyway.

 

[Teoidus]

It could still be useful for pseudo-blocks.

What do you average with the method now?

 

[efattah]

It could still be useful for pseudo-blocks.
What do you average with the method now?

I'm still averaging 16.7 (Ao50=16.3, Ao12=15.3). I have had an 11 and a 12 in the same Ao5, and I recently had probably my most lovely solve, a full step 9.10 using CsTimer hitting the spacebar on the splits, and the splits were 2.02 (corners), 4.74 (E2L), 2.34 (L5E).

I'm still using 1-look L5E, I know a few of the 2-look LSE cases but that's my next task (to learn them all).

Some of the LSE algorithms double as E2L pair algorithms. This is starting to allow me to select the E2L algorithm on the fly (from several choices of the same case), which allows partially setting up the next pair (as each alg affects the other pieces and L/R slightly differently). The overall method could be optimized for 10 years and still have new tricks. That's what I enjoy about it, I'm always finding new tricks.

 

[Neuro]

So method neutrality is something I've been interested in for a while now, and I think I've finally got a basic plan to method neutrality. While I don't think it's particularly useful if you are already extremely good at a single method, it's still an interesting concept so I thought I might as well explain my system for those who are interested. Here's the document I made. Enjoy and leave any suggestions you have!

https://docs.google.com/document/d/1kbeFfLPNEd3IODrMZtpsj0XzJ-NwOCQxiStYF6Q45IU/edit?usp=sharing

 

[Teoidus]

tbh I think petrus/zz neutrality can be very powerful

 

[Neuro]

Sounds interesting, the main reason I didn't put Petrus on there is b/c I really don't like it. I find the ergonomics to be pretty bad which basically cancels out the movecount advantage for me. Does sound good though, may do some tests later. Any other suggestions as to what to put onto the doc?

 

[Teoidus]

I think it may be better to first solve a rouxblock and then expand to 2x2x3+EO with <R,r,U,M>. More ergonomic and allows you to one-look 2x2x3's

Waterman/Roux neutrality could be interesting if you see an easy layer