The New Method / Substep / Concept Idea Thread

[Teoidus]

Guroux's gotten 30 before

avg movecount seems like it's around 44 if we go by efattah's claims, which is low but by no means crazy

 

[Shiv3r]

Guroux's gotten 30 before

avg movecount seems like it's around 44 if we go by efattah's claims, which is low but by no means crazy

It is crazy if you are talking about actual movecount in speedsolves. Average movecount for roux is about 48 in speedsolves, and ZZ is over 50 in speedsolves. CFOP is over 60. As far as I can tell, Efattah's movecount estimates are based off of movecounts in speedsolves not the most optimal solution.

 

[shadowslice e]

It is crazy if you are talking about actual movecount in speedsolves. Average movecount for roux is about 48 in speedsolves, and ZZ is over 50 in speedsolves. CFOP is over 60. As far as I can tell, Efattah's movecount estimates are based off of movecounts in speedsolves not the most optimal solution.

Most good rouxers will often be below the oft quoted 48 stm and I'm sure other methods are similar because of all the tricks you can learn.

 

[Shiv3r]

Most good rouxers will often be below the oft quoted 48 stm and I'm sure other methods are similar because of all the tricks you can learn.

mmk. I think that ZZ is still slightly higher than roux however. and CFOP is far above. The most move-optimized CFOP is FreeFOP, which I think could actually get pretty low movecount solves.

 

[Teoidus]

mmk. I think that ZZ is still slightly higher than roux however. and CFOP is far above. The most move-optimized CFOP is FreeFOP, which I think could actually get pretty low movecount solves.

If anything I think this is at least proof that movecount isn't the sole measure of a method's potential.

CFOP is ~60, ZZ without any of the large sets ~57 and with the large sets ~48, vanilla Roux is ~48 and Roux with advanced tricks ~45

 

[efattah]

Sorry I still haven't posted the algorithms but more interesting is the probability of sub-30 movecounts. Let's look at the solve I had:

1. CLL skip; 1 in 162, but only if you always solve a true face. Since I solve with EG, 2/3 of the time the first face is an EG face not a CLL. So in LMCF the real chance of CLL skip is 1 in 486, unless of course you are so good in inspection that you can see in the inspection that you can get a CLL skip if you make a face and not an EG face.

2. I had 2 pre-solved edges after the CLL skip. I don't know the exact probability of this but from experience I'd estimate 1 in 8. However for this analysis we need to look at the probability of having AT LEAST 2 edges pre-solved (not exactly 2, but at least two). This would drop it to around 1 in 7.

3. Midge orientation skip. This is more tricky. When solving the last ledge/redge normally you do the 'solve last redge while simultaneously orienting the midges.' In that sense there is no skip. However when solving the last E2L pair you can sometimes just solve the last ledge/redge at the same time, and in so doing you finish both the L and R faces and 'hope' the midges end up oriented. This is what happened in my solve. If you 'gamble' and hope for a midge orientation skip, the chance of getting it is 1 in 8. But honestly I only make this gamble about 1 in 5 solves.

So, you can do a 'normal' LMCF solve where you start with EG faces and always do the L5E step normally. This is the best for average movecount. But if you aim for fast singles and extreme low movecounts, you are better off making a solid CLL face and hoping for a CLL skip and then gambling on the L5E and hoping for a midge orientation skip.

1. Normal solve chance of sub-30 movecount:
1 in 486*7*8*5 = 1 in 136,080

2. Gamble for low movecount and the chance is
1 in 162*7*8 = 1 in 9072

And yet the truth is with CLL having an average of 9 (?) moves per algorithm, a CLL skip drops the average movecount from 44 to 35. So any solve with a CLL skip and you are running a 35 move solve. Which is 1 in 162 if you choose to start with CLL. Interestingly somrandomkidmike's 8 second Waterman solve played out exactly like my 8.88; he had a CLL skip and also skipped a step in the L5E.

 

[Shiv3r]

New PB with Lewis method: 49.423.

Just wanted to put that out there. wasn't even a nice solve, just randomly had no pauses and good lookahead one solve.

 

[Teoidus]

Can you post the algs please?

Doesn't seem like they're being revised at this point. You could've posted them just now?

 

[efattah]

Okay, this took me some time to compile out of my head!
Here is the LMCF method PDF with algorithms. Welcome to the realm of occasional 27-35 move singles.

 

[Metallic Silver]

Can this method be possible?
ZFOP-CT
1. EO Cross
2. ZZF2L (sometimes can use 3 or 2gen multislot)
3. TSLE
4. TTLL

 

[Shiv3r]

Can this method be possible?
ZFOP-CT
1. EO Cross
2. ZZF2L (sometimes can use 3 or 2gen multislot)
3. TSLE
4. TTLL

literally what a ZZ solver (colorfulpockets or Chris Tran)would do on a lucky scramble

 

[Teoidus]

43 STM 2GR

R' D' L' B U B L' F' R F' U2 R' B' L2 F2 U' B U L' U'
y' z' // insp
y' r2 U' r' R2 U' R' // EOPair 6/6
R2 U' R2' y // CPLine 3-1/8
r R u2 M' E r2' u // Block 7/15
R2 U' R2' U2 R U R2' U' R U z' // F2L 10/25
U' R U R' U R U' R' U R U' R' U R U2' R' U2 r2 // 2GLL 18/43

A good example of a more advanced way of going about EOPair: often you can take advantage of large strings of <F,f,U,u> by applying a y' and executing them <R,r,U,u>. Because of this trick, this solve doesn't have any L/B/D/F moves at all. (also 2GLL is literally 40% of the whole thing, lol)

Current average movecounts for all 26 full 2GLL solves that I've done so far is 43.65, with median 43 and standard deviation 5.52. This is pretty far below projected (49 STM) but I think it's good to have that buffer as these solves aren't strictly speedsolves and more just me doing whatever seems half-decent on alg.cubing.net.

For comparison, when I do a similar thing with Roux I can usually average 45 moves (n = 100) but in speedsolves my movecount is more around 48.

 

[genericcuber666]

For basic phasing there's 3 cases. 1 is 3 moves 1 is 4 moves and the other is 7. So an average just under 5 a normal insert is 3 moves so it's only ~2 moves more

I'm not saying this makes it viable, but phasing opposite edges is usually around 3-4 moves, which really isn't that much. But I agree about ELL not being very good, unless you use it only when the cases come up, not as a substep. And it's only around 40-50 algs, not 100.

 

[efattah]

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.

 

[Shiv3r]

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.

Im guessing due to this you sometimes have an L5E with non-matching L and R faces?

 

[crafto22]

Im guessing due to this you sometimes have an L5E with non-matching L and R faces?

What? No, you can just adjust whichever face doesn't match/is solved and then do your L5E if that's a problem...

 

[Teoidus]

The setup moves are for the E2L algs. they likely start with the slots for the edges to be solved into at UL and UR, if we go off of the example solves that efattah's posted, so sometimes you have to do L or R moves to place your slots in those positions

 

[Neuro]

For LSE, what if we were to insert one of the L/R edges, and then use an alg to insert the remaining edge while orienting the rest? It seems like the algs would be pretty short, one could easily use pseudo to shorten the setup(which is already at most 3-4 moves), and the cases wouldn't be *too* difficult to recognize. Only downside I see is alg count (150ish without y2 symmetry)

4 flip cases, 2 flip cases, and 0 flip cases.
--10 2 flip, 4 4 flip, 1 0 flip

Last edge can be in 1/5 places
--10 possibilities taking orientation factor

150 algs

 

[efattah]

Im guessing due to this you sometimes have an L5E with non-matching L and R faces?

75% of the time you are doing L5E with non-matching L and R faces on U. The trick is while you executed the L5E midge orientation algorithm by muscle memory, you examine the corners and centers and figure out in advance which move is needed to correct the L and R slices to match (L', R2, and R are the only ones which smoothly flow into midge permutation; R' does not). Immediately upon finishing the midge orientation you instantly roll into the L/R correction move then from there into midge permutation. L5E is so fast I can usually do it in around 2.3 - 2.7 seconds despite my very slow TPS. A fast Rouxer could do it in 1.4 or less.

In the situation where you still have two unsolved edges at UR and UL *and* the L and R faces (on U) each match or are of opposite color, you can finish the solve with Roux LSE if you are very good at Roux. If L and R do not match, edge recognition for Roux LSE is essentially impossible. Even so sometimes the last E2L pair leaves you with only one unsolved edge (at UR or UL), in which case L5E is faster than Roux LSE since it has only 2 steps rather than 3 and fewer moves.

 

[efattah]

For LSE, what if we were to insert one of the L/R edges, and then use an alg to insert the remaining edge while orienting the rest? It seems like the algs would be pretty short, one could easily use pseudo to shorten the setup(which is already at most 3-4 moves), and the cases wouldn't be *too* difficult to recognize. Only downside I see is alg count (150ish without y2 symmetry)

4 flip cases, 2 flip cases, and 0 flip cases.
--10 2 flip, 4 4 flip, 1 0 flip

Last edge can be in 1/5 places
--10 possibilities taking orientation factor

150 algs

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.