The New Method / Substep / Concept Idea Thread

[crafto22]

With all the talk of TEG1, I realized TLEG1 could be a game changer for WaterRoux. With TLEG1 it becomes possible on many solves to see the entire first block AND the corner solve in 1-look. It still takes an expert to do so, but this would finally resolve the last hurdle of Roux which is to put the CMLL recognition into the inspection phase; while still maintaining a lower move count than regular Roux, by a quite significant amount.

Better still, you don't need full TEG1 for WaterRoux since the left block is always solved, so you only need four TLEG1 sets, L+, L-, R+, and R-, as well as normal LEG1 and CMLL optimized for an unconstrained left block. So this would be 252 corner algorithms in order to be 'in range' of a 1-look solve of the left block and all the corners. An example:

Scramble:
B2 R' D2 B2 R2 F2 D F2 U B' R' F' R2 B F U2 B' R' U'
y M' S U S' // FB (4/4)
R2 U' R' // yellow corners (or JUST R' if you solve the white corners)
// Now solve corners with TLEG1, L+ set
[I would comment that if you are good enough to solve with non-matching corner sets, it only takes 1 move to put the white corners in, meaning just 5 moves to 1-look the corners and first block]

In the above example we need to see 7 moves into the future in order to 1-look the yellow corners which is hard but within range of a master (or 5 moves to 1-look the yellow/white not matching corners). After that, there are just 5 L/R edges left, of which we need to solve 3 in order to reach LSE. However half the time one is already solved at random, meaning we are one E2L pair away from LSE. Allowing no constraints on where this pair is, sometimes this pair solves the UL slot and a random redge, putting us into a Waterman L6E situation. However, I have started optimizing the Waterman L6E sets, and Waterman Set 2 is the one that occurs most often by far, and I have so far optimized it to an amazing 9.4 moves while improving the speed and ergonomics of the algorithms. So even in the situation where you end up with UL solved, it means in most cases you can solve the last two redges and orient the midges in less than 10 moves, or 11 moves if you include 1 set up move.

If you 1-look the first block and corners, this is around 15-17 moves at essentially max TPS since you know exactly what to do; so this could be 1.7 seconds. Then you solve one E2L pair in 1 second, then you finish with either Roux EOLR, LMCF L6E, or Waterman L6E, the worst case being around 2 seconds for that operation. So a 1-look solve would be around 4.7 seconds for an expert.

As WaterRoux-TLEG1 cuts at least 1-2 more moves off the average move count, then it will be even lower than regular WaterRoux, which was already lower than Roux. But the bigger advantage is being able to 1-look the corners.

I definitely agree that TLEG-1 is a great idea for WaterRoux, but imo we're still missing one thing that would make WaterRoux perfect: a good way to do L7E. If could get L7E to under 15 moves (I'm certain this is possible, the question is how), the entire solve would be:
FB+Corners: 17
E2L pair: 7
L7E: 14
Total: 38 STM

 

[efattah]

Well I created that L7E document which, to be fair, only solves the case where the last two redges are on the R layer already; but more recently I believe the best way to solve L7E is to solve one redge while orienting the other 6 edges; then you finish with the last two steps of Roux. Solving one redge while orienting the other 6 edges should not take hardly any more moves at all vs. orienting 6 edges, just as the L7E document showed that solving those cases did not take any more moves than solving the equivalent Waterman L6E cases.

The last thing that is needed is the ideal edge orientation recognition system. It is slightly more complicated than regular Roux but not much.

 

[Neuro]

TLEG sounds good. What's surprising to me though is that the case count for all of the corner sets is 256 algs, still less than full ZBLL. One of the last 2 redges+orientation is pretty smart IMO, I just hope there isn't a ridiculous number of cases.

EDIT: 256 is only if in the twisty cases the front corner is the one twisted. If you have cases with the back twisted then alg count shoots to 428 (TCMLL+/- front/back, TLEG +/- front/back) which is about the same as ZBLL :/

 

[efattah]

For WaterRoux L7E, we try to solve UL + UR, all the midges, plus one other redge, either DR, FR, or BR.

In the first case none of those three edges have any L/R edges in them.
In the second case one of the redge slots is filled with another redge, either oriented or disoriented (3 cases as in Waterman Sets 1,2,3 except UL is also unsolved).

So there are four cases, and each of those cases we must orient the other 6 edges which has the same number of cases as Roux LSE.

So the total number of algorithms is 4 x 7 = 28. Mind you there are minor variants for the DR/BR cases but 28 main algorithms for this style of L7E.

EDIT: The approximate number is 28. For the case where FR is disoriented, there is the possibility of odd numbers of disoriented LSE edges.

 

[efattah]

I generated an example L7E orientation:
R U M U' R' U' M2 U [8]
This solves disoriented FR while orienting four bad edges on U and one bad edge on D.

To see the case it solves, execute the inverse: U' M2 U R U M' U' R' on a solved cube.

 

[efattah]

Another case L7E case:
F U' M2 U F' [5]
This solves disoriented FR while orienting one bad edge at UR.
Run the reverse to see the case: F U' M2 U F'.

Another case:
U M' U2 r U M2 U' r' U [9]

So it looks like most cases are 5-10 moves, plus 4.5 moves to permute the midges.

 

[Thermex]

@crafto22 btw that solve you got was perfectly following the method I thought of a while ago.
1. FB
2. D-layer corners in random orientation and the TLEG
3. Solve 3 redges (you happened to get a skip here)
4. LMCF L6E

So yeah, I think to find the next great method both a faster way to do L7E and a way to solve 3 redges in an algorithm need to be generated.

@efattah btw I just finished my second TEG set today, It's going great so far. So far I've finished the DFR- hammer set and the DFR- spaceship set. The average alg is about 8.75 moves. Also the method you brought up earlier there was EXACTLY the same as the method I proposed on your LMCF thread.

 

[Thermex]

I was just testing out my method here and got this absolutely rediculous solve, probably because I hand scrambled this though

FB on blue (8 moves):
M U' M' U2 M2 (z) (x') M' U M

Two corners on bottom in random orientation (2 moves):
U' R2'

TEG (8 moves)
(y) F R U R' U' R U' R' (I happened to get one of the hammer cases I generated yesterday)

Three edges on u-layer (8 moves):
U2 M' U M U2 M' U M (I got lucky and got an ELL for this step, this happens about 1 in 7 solves)

L6E (I did a z rotation so that the top layer edges+DF and DB were unsolved and finished off the solve with Roux LSE, 7 moves)
M' U' M U' M2 (EOLR) U (AUF) M2 (sort-of 4c skip)

Total was 31 moves without any real skips, I feel like this method might really work, although this is certainly not a normal solve.

 

[crafto22]

Another case L7E case:
F U' M2 U F' [5]
Run the reverse to see the case: F U' M2 U F'.

Lmao the alg and its inverse are the same XD

 

[efattah]

I was just testing out my method here and got this absolutely rediculous solve, probably because I hand scrambled this though

FB on blue (8 moves):
M U' M' U2 M2 (z) (x') M' U M

Two corners on bottom in random orientation (2 moves):
U' R2'

TEG (8 moves)
(y) F R U R' U' R U' R' (I happened to get one of the hammer cases I generated yesterday)

Three edges on u-layer (8 moves):
U2 M' U M U2 M' U M (I got lucky and got an ELL for this step, this happens about 1 in 7 solves)

L6E (I did a z rotation so that the top layer edges+DF and DB were unsolved and finished off the solve with Roux LSE, 7 moves)
M' U' M U' M2 (EOLR) U (AUF) M2 (sort-of 4c skip)

Total was 31 moves without any real skips, I feel like this method might really work, although this is certainly not a normal solve.

That doesn't really count as a lucky solve. A poor first block (8), ordinary TEG1, and solving three redges in 8 moves is pretty standard even with E2L triplet algorithms. The 4c skip almost made up for the poor first block. I'm telling you WaterRoux-TLEG1 has an insanely low move count with excellent ergonomics and no rotations if you use TLEG1, and this example solve at 31 moves is probably only slightly lower than average...

 

[Thermex]

That doesn't really count as a lucky solve. A poor first block (8), ordinary TEG1, and solving three redges in 8 moves is pretty standard even with E2L triplet algorithms. The 4c skip almost made up for the poor first block. I'm telling you WaterRoux-TLEG1 has an insanely low move count with excellent ergonomics and no rotations if you use TLEG1, and this example solve at 31 moves is probably only slightly lower than average...

The reason I considered this lucky was partly the L6E which was really easy, but also the fact that I happened to get one of the TEG algs I generated and also an ELL that I knew. But 8 moves is a poor first block? I thought that was like average (it's what I average anyway, but I've only been using Roux for a month or two). Also isn't the WaterRoux you guys are proposing here basically the same as the one I brought up in your LMCF thread? It's the same idea where you 1) solve a first block 2) put in a bar of corners+TLEG (that wasn't my original idea but it's what I started thinking about a few days ago) 3) L9E in two steps

And finally, do you think it's more efficient to do L9E by doing
A) Solve two redges, then finish off with L7E, or
B) Solve three redges, then finish off with LMCF L6E

 

[efattah]

The reason I considered this lucky was partly the L6E which was really easy, but also the fact that I happened to get one of the TEG algs I generated and also an ELL that I knew. But 8 moves is a poor first block? I thought that was like average (it's what I average anyway, but I've only been using Roux for a month or two). Also isn't the WaterRoux you guys are proposing here basically the same as the one I brought up in your LMCF thread? It's the same idea where you 1) solve a first block 2) put in a bar of corners+TLEG (that wasn't my original idea but it's what I started thinking about a few days ago) 3) L9E in two steps

And finally, do you think it's more efficient to do L9E by doing
A) Solve two redges, then finish off with L7E, or
B) Solve three redges, then finish off with LMCF L6E

Indeed the method is generally similar to what you suggested with the important difference that as we have proposed it, it is rotationless and the two EG corners are solved on a different face, not the same face as the first block.

So the rotationless method:
FB on left
Twisty EG corners on lower right
Solve corners with twisty LEG1 rotationless
Now, based on what you see, either
(A) solve two redges at once then finish with 3-look L7E (solve one redge + orient midges, we calculated 39 algorithms)
or
(B) solve UL and two redges at once then finish with 2-look L5E
or
(C) solve three redges at once (somrandomkidmike developed and used this in his waterman solves), then finish with either 2-look LMCF L6E or 3-look Roux LSE

We should really be moving this discussion into the WaterRoux thread...

 

[Thermex]

@efattah you're totally right, that is the main difference to our methods. To test out which method of ours is better, I took the TEG hammer set I made yesterday and applied it to my method (preserving DL, DB and DR edges while solving corners) and your method (preserving FL, DL and BL while solving corners) to see if the cases would preserve our pre-solved edges. Only one or two TEG algs preserved the 3 ledges in your guys' method, and almost all of the TEG algs preserve the d-layer edges used in my method. My method is also almost completely rotationless if you solve FB on the d-layer (which is realy really easy) and use a TLEG alg+three u-layer edges. The only rotation would be a z rotation after these for L6E. I also feel like the third option you gave for L9E (three redges+LMCF L6E) is the best way to go until a better way of doing L7E is developed. Could you leave me a link to the place somerandomkidmike has these algorithms or talks about them? I'm very curious. And yes lets move this discussion over to the waterroux thread, you can write your reply to this post there. I posted this exact post there too, so you can see it and respond to it.

 

[Shiv3r]

Hey, basically not related at all, but I think we should "gen" some algs for Oll Parity+CMLL for Meyer(this is basically going to end up being manipulating the corners around then doing a parity or souble parity alg then maybe some more setups, like POLL is).
a few of us should collaborate and make an (atleast mostly) complete doc of OP+CMLL. Anyone want to help me?

also I think that if you know full EG, CLL, TCLL, and TEG, then the amount of moves needed for a face is something like 5 max. onelooking would be so insanely easy.

 

[Thermex]

Hey, basically not related at all, but I think we should "gen" some algs for Oll Parity+CMLL for Meyer(this is basically going to end up being manipulating the corners around then doing a parity or souble parity alg then maybe some more setups, like POLL is).
a few of us should collaborate and make an (atleast mostly) complete doc of OP+CMLL. Anyone want to help me?

also I think that if you know full EG, CLL, TCLL, and TEG, then the amount of moves needed for a face is something like 5 max. onelooking would be so insanely easy.

I'll join, although I don't know how to generate 4×4 algs yet. If you could show me how to do that I would definitely generate some algs for this, as it could be very useful. Maybe if we can get 7 people we could each do a set? Also with TEG, EG, TCLL and CLL I average around 2.5 moves for a face, and the maximum number of moves to solve a face is three. Btw I just finished my third TEG set today and now have DFR- hammer, spaceship and stollery done (yay)

 

[Shiv3r]

I'll join, although I don't know how to generate 4×4 algs yet. If you could show me how to do that I would definitely generate some algs for this, as it could be very useful. Maybe if we can get 7 people we could each do a set? Also with TEG, EG, TCLL and CLL I average around 2.5 moves for a face, and the maximum number of moves to solve a face is three. Btw I just finished my third TEG set today and now have DFR- hammer, spaceship and stollery done (yay)

for most of OP+CMLL I don't expect you need to be able to gen algs, in fact I was going to intuitively come up with something like meep did for POLL. I need someone who is better at creating spreadsheets to help by creating it, then adding [email protected]

 

[Teoidus]

Got bored today and decided to calculate some 2GR skip chances:

Let me know if any of them are incorrect

1) LL skip
P(LL skip) = 1 / (4 CP * 3^3 CO * 4!/2 EP / 4 AUF) = 1/324

Compare to LL skip chances for other methods:
CFOP: P(LL skip) = 1 / (4! CP * 3^3 CO * 4!/2 EP * 2^3 EO / 4 AUF) = 1/15552
ZZ: P(LL skip) = 1 / (4! CP * 3^3 CO * 4!/2 EP / 4 AUF) = 1/1944
ZZ-b: P(LL skip) = 1 / (4! CP * 3^3 CO * 4/2 EP / 4 AUF) = 1/324
ZZ-CT: P(LL skip) = 1 ayy lmao

So LL skip chance is equal to ZZ-b's skip chance, with ~half the algs (84 2gll vs 167 zzll).

2) COLL skip
P(COLL skip) = 1 / (3^3 CO) = 1/27.

Compare this to COLL skip chances for other methods:
CFOP: P(COLL skip) = 1 / (4! CP * 3^3 CO * 2^3 EO / 4 AUF) = 1/1296
ZZ: P(COLL skip) = 1 / (4! CP * 3^3 CO / 4 AUF) = 1/162
ZZ-b: P(COLL skip) = 1 / (4! CP * 3^3 CO / 4 AUF) = 1/162

This is pretty crazy if you think about it. The probability of COLL skip in 2GR is equal to the probability of an OLL skip in ZZ.

3) Sune-solvability (LL solvable by a single Sune, Sune', Backsune, or Backsune')
P(Sune-solvable) = P(Sune or Antisune OCLL) * P(solvable by sune variant | Sune OCLL) = 8/27 * 1/6 = 4/81 = 1/20.25

Compare this to sune-solvability for other methods:
ZZ: P(Sune-solvable) = P(CP solved) * P(Sune-solvable | CP solved) = 1/6 * 4/81 = 2/243 = 1/121.5
CFOP: P(EO solved) * P(Sune-solvable | EO solved) = 1/8 * 2/243 = 1/972

This is also pretty crazy--the probability that your LL ends up just being a 7 move sune variant + AUF is higher than the probability of an OLL skip in ZZ.

----------------------------------------------------------------

Additional fun facts
Let's look at the probability that at least one of your solves has a <= 9 move last layer in a standard competition avg5:
Let p = P(1 lucky LL) = P(LL skip or COLL skip or Sune-solvable) = 1/324 + 1/27 + 4/81 = 29/324 (~= 0.089, about 1 in 11)
P(Lucky LLs >= 1, n = 5) = (5 nCr 1) p (1-p)^4 + (5 nCr 2) p^2 (1-p)^3 + (5 nCr 3) p^3 (1-p)^2 + (5 nCr 4) p^4 (1-p) + (5 nCr 5) p^5 = 37.43% chance of getting at least 1 lucky LL in competition

Or, let's look at the probability of at least one of your solves having a <= 9 move last layer if you just sat down and casually did an avg12:
P(Lucky LLs >= 1, n = 12) = sum (i = 1 .. 12) of (12 nCr i) p^i (1-p)^(12-i) = 67.5% chance of getting at least 1 lucky LL during an avg12

This is the entire last layer taking no more than 9 moves (!). Almost all of these solves will be in the range of 36-45 moves. When performed by an "expert" at 8 tps, these solves would be in the range of 4.5-5.6 seconds. This means that, every time he competes, an expert would have a 37.43% chance of getting a 4.5-5.6 second solve (I'm sure 8tps is a conservative estimate, given that many have reached 9-10 tps which would make times in 4.xx range or even sub-4 achievable, and this does not even take into account probabilities of getting lucky during prior steps).

 

[ShyGuy1265]

I made a face first method a little while ago, but it had a very high alg count and awkward lookahead. I just changed it to fix those problems.

Original method: https://www.speedsolving.com/forum/threads/the-new-method-substep-concept-idea-thread.40975/page-146

Step 1: face-1 corner

Step 2: keyhole 3 e-slice edge

Step 3: non-matching last slot

Step 4: COP; orient last layer corners while permuting first layer corners (23 algs)

Step 5: EOP; orient last layer edges while permuting first layer edges (29 algs)

Step 6: PLL (21 algs)

Total alg count: 73 (5 less than CFOP)

I took out the CP+last slot because that was awkward for recognition and lookahead. The method also went from ~330-370 algs to 73 algs

 

[Shiv3r]

okay guys made a sheet but it doesn't have anything really on it yet and needs major restructuring and stuff.
but comment on the one box and I'll add to edit
https://docs.google.com/spreadsheets/d/1cxz3Scm8WlMHIDLC7nzc0a8RQQCwn38v7G_bsfCySiY/edit?usp=sharing

 

[Hazel]

I came up with an idea but I'm not sure how good it would be, here it is:
Step 1) Petrus block + 1 F2L pair (see below)
Step 2) Insert 4th First Layer corner without regard to its orientation (making sure the edge that should go in FD isn't connected to it), then COLL/some 3x3 form of TCLL
Step 3) Insert 4th First Layer edge while solving the orientation 3-4 LL edges (number depends on location/orienta
Step 4) L5E (not sure how many algorithms there would be)

For step one, there's many ways to solve this, that's why I didn't separate it into multiple steps:
- Solve a Petrus-style 2x2x3 block, then insert 1 F2L pair
- Solve Roux-style 1x2x3 block on the left, then solve a 2x2x2 block in the back
- Solve CFOP-style cross (minus 1 edge), then 3 F2L pairs

For step 3, what I mean is this:
Say the bottom side is white. While solving the 4th white edge, all the yellow edges IN THE U LAYER would be oriented (unless the non white/yellow edge is in FR but oriented incorrectly, the only 3). I say in the U layer because most likely, there will be one in FR, and it's orientation doesn't matter right now, and there would also be a non-yellow edge in the U layer.

Here's an example solve if you still don't understand:
Scramble: B' L B2 U F2 R' U2 F D B D2 L F2 R2 B2 R' U2 R U2

Step 1) z2 R' F D' Rw' U' Rw U B F2 R M U' Rw R B U' B2 R B
Step 2) R U2 R' U R' U' R U' R' U2 R
Step 3) M' U' M
Step 4) U2 L F2 U F2 R F U F' U' R' U' F2 L'

yes I know my efficiency for step 1 was absolutely horrible, but I'm terrible at block-building. People who are pretty good at block-building could probably do that with MUCH less moves. I just wanted to get the point across of what the method is, if it's even viable.