The New Method / Substep / Concept Idea Thread

[Arc]

complex reduction method (CRM)

1. solve all edges in the e slice and orient edges in the u and d layers (intuitive)
2. permute the edges while orienting corners on L (algs)
3. permute the corners while orienting the corners on R (algs)
4. permute the remaining corners

this has the mathematical advantage of permuting and orienting something at the same tiem for every step, just like in the snyder method, i think it would be able to get 40 moves average really really easy

So essentially a corners last variant? I really doubt that it could be very efficient because you have to work around the solved edges which makes it really inefficient. Also, you permute edges while orienting corners algs will not be very good as the edges would work more naturally in the {U,D, double turns} movegroup but the corners would be more {R,U,D,L,F} (which incidentally is not very good either as most algs are 2 to 4 gen for a reason).

I just want to point out that step 4 doesn't orient and permute at the same time.

 

[Sue Doenim]

Here's a pretty cool Yau-ZZ thing I thought up.
1) 2 Opposite centers
2) Build 2 opposite cross edges (your line) and another non U edge, oriented, just like yau but with a random edge instead of the 3rd cross edge
3) Finish centers
4) Pair remaining edges, making sure F2L and cross edges end up oriented
5) ZZ F2L
6) LL as usual
4 probably works best with M slice pairing.

 

[Hazel]

So - an algorithmic approach to Roux LSE. It's less efficient and worse in the long run, but probably easier to get a hold of.
So instead of doing EO -> ULUR -> L4P, you do EODB (or DF) -> L5E
I already have L5E algs here

 

[Neuro]

So - an algorithmic approach to Roux LSE. It's less efficient and worse in the long run, but probably easier to get a hold of.
So instead of doing EO -> ULUR -> L4P, you do EODB (or DF) -> L5E
I already have L5E algs here

Trust me, doing EOLR and L4EP is probably the best way for a human to solve LSE. This and a few other LSE subsets may be useful under very certain circumstances, but even then it would be limited to a few useful algs, as most of them are just doing LR into L4EP anyway. Long been trying to come up with a super efficient alg based way to do LSE and all of them have fallen short for speed. EOLR is pretty easy to learn anyway.

 

[efattah]

Trust me, doing EOLR and L4EP is probably the best way for a human to solve LSE. This and a few other LSE subsets may be useful under very certain circumstances, but even then it would be limited to a few useful algs, as most of them are just doing LR into L4EP anyway. Long been trying to come up with a super efficient alg based way to do LSE and all of them have fallen short for speed. EOLR is pretty easy to learn anyway.

EOLR+L4EP is a good method and proven, but I won't say that it is faster than the LMCF method of doing L6E which is basically the following:
1. Place one of UL or UR (or both) into the UL or UR slots in any orientation or permutation (this step is skipped 60% of the time)
2. Solve remaining UL/UR while orienting all edges
3. Permute M slice

Step 2 is the only step which uses algorithms and there are quite a few (32 direct set, 32 i-set, 32 d-set, 32 x-set, 32 r-set, 4 dd-set, 4 oo-set, 4 pure m-slice, 4 do-set, 4 dds-set, 4 dos-set = 184 cases of which around 2/3 are reflections).

EOLR claims to use around 60 algorithms but you also need reflections making it around 120, so similar.

The probability that UL doesn't contain either UL or UR is 4/6. In that same situation the probability that UR does not contain either UL or UR is 3/5. 4/6 * 3/5 = 12/30. So the probability that neither UL nor UR contains either of their respective edges is 12/30. That means the probability that they DO contain such an edge is 18/30. So for LMCF L6E, step 1 is skipped 18/30 solves, 60% of the time. In those 60% of cases I think the LMCF method is faster than EOLR. In the 40% of cases that neither UL nor UR contains either of their respective edges (in any permutation or orientation), then EOLR might be a bit faster. However, the LMCF method has another advantage in that it can be used for all sorts of hybrid methods where the L and R slices are not aligned, or out of phase by 90 degrees. Roux EOLR or any Roux LSE fails if the L and R slices are not aligned because the edge orientation cannot be easily determined.

 

[Pyjam]

Here's a pretty cool Yau-ZZ thing I thought up.
1) 2 Opposite centers
2) Build 2 opposite cross edges (your line) and another non U edge, oriented, just like yau but with a random edge instead of the 3rd cross edge
3) Finish centers
4) Pair remaining edges, making sure F2L and cross edges end up oriented
5) ZZ F2L
6) LL as usual
4 probably works best with M slice pairing.

That's what I've done for years before I switched to Leor which is more optimised.

Here are some minor improvements:
2) Build DF and DB edges + add any other premade pair (why not a U edge?) but the DL edge is preferable
4) Pair the edges on the M slice. When done, there are always unoriented pairs and it's easy to oriented them with the cube rotated on the z-axis and (F R F') triggers or something like that. Sometime it's even possible to insert a pair in FL or BL.
5) Start F2L with z' rotation. The DL edge is already solved. This helps the transition a lot.
6) LL with a mix of COLL and ZBLL

 

[Thom S.]

complex reduction method (CRM)

1. solve all edges in the e slice and orient edges in the u and d layers (intuitive)
2. permute the edges while orienting corners on L (algs)
3. permute the corners while orienting the corners on R (algs)
4. permute the remaining corners

this has the mathematical advantage of permuting and orienting something at the same tiem for every step, just like in the snyder method, i think it would be able to get 40 moves average really really easy

Step 4 is CPLL which unfortunitly won't give you sub 40 Movecounts as They are too long

Here's a pretty cool Yau-ZZ thing I thought up.
1) 2 Opposite centers
2) Build 2 opposite cross edges (your line) and another non U edge, oriented, just like yau but with a random edge instead of the 3rd cross edge
3) Finish centers
4) Pair remaining edges, making sure F2L and cross edges end up oriented
5) ZZ F2L
6) LL as usual
4 probably works best with M slice pairing.

Although any 3rd edge is Step 2 can add efficiency, it is probably friendlier to just do 3 Cross Edges and have some moves more during 3x3.
Edge pairing on either E or M is more personal preferrence then/than(really not sure currently) method dependent but maybe yours is an exception and I'm wrong

 

[Sue Doenim]

That's what I've done for years before I switched to Leor which is more optimised.

Here are some minor improvements:
2) Build DF and DB edges + add any other premade pair (why not a U edge?) but the DL edge is preferable
4) Pair the edges on the M slice. When done, there are always unoriented pairs and it's easy to oriented them with the cube rotated on the z-axis and (F R F') triggers or something like that. Sometime it's even possible to insert a pair in FL or BL.
5) Start F2L with z' rotation. The DL edge is already solved. This helps the transition a lot.
6) LL with a mix of COLL and ZBLL

I was thinking something along the lines of ignoring U edges so you wouldn't have to worry about as many, and half the time, you wouldn't even be able to orient them all. That's pretty cool though.

Although any 3rd edge is Step 2 can add efficiency, it is probably friendlier to just do 3 Cross Edges and have some moves more during 3x3.
Edge pairing on either E or M is more personal preferrence then/than(really not sure currently) method dependent but maybe yours is an exception and I'm wrong

I was going for a ZZ style F2L, but a CFOP style LL. You'd want to use than here.

 

[Thom S.]

I was going for a ZZ style F2L, but a CFOP style LL. You'd want to use than here.

Really bad feeling when you aren't sure about which word to use.

Not sure what to say about your idea. It could either be genious to neglect the U Layer edges or it could be the worst idea ever. I mean, it's possible to do EO + OLL Parity algorithms before 3xe Stage which could be more efficient and COLL/ZBLL/WV is even more beneficial on big cubes which wouldn't be possible without
But it gives you a shorter pause during EO Edge Pairing and lookahead

 

[gogozerg]

1. Place one of UL or UR (or both) into the UL or UR slots in any orientation or permutation (this step is skipped 60% of the time)
2. Solve remaining UL/UR while orienting all edges
3. Permute M slice

Good old corners-first approach. Not hard to learn, given the symmetries and obvious cases, knowing <20 sequences and tricks should be enough. I always wondered why people gave up using it.

Roux EOLR or any Roux LSE fails if the L and R slices are not aligned because the edge orientation cannot be easily determined.

Not sure about this. It certainly makes it less obvious, but I feel it's possible with good look-ahead skills.

 

[Arc]

Just some stats about optimal LSE vs EOLR

 

[Thom S.]

Roux EOLR or any Roux LSE fails if the L and R slices are not aligned because the edge orientation cannot be easily determined.

Fortunitly it can. After CMLL with different allignments you know which Edge is your special one so you can still do it if your head wraps around it fast enough.
The only exception is if you have e.g.: left-yellow on top, right-blue on top and after CMLL you see three unoriented edges in U and a Blue Spot at dF(both blue edges are in D) as there are 2 orientation for blue edges. Using only opposite colors can still give you effeciency while lookahead is not as bad

 

[efattah]

Just some stats about optimal LSE vs EOLR

I have never done a full calculation for all 184 cases of LMCF L6E, but the approximate average is 8.3 for the UL+UR+orient, plus 3.75 to permute the midges (correct me if I'm wrong on that), and the first step is 3 moves, but skipped 60% of the time, so 0.40 * 3 = 1.2. So the total for the LMCF approach would be theoretically 13.25 moves. However this does not account for the fact that in 60% of cases you need to do an M move to prepare the M slice edges for the UL+UR+orient step, so that adds another 0.6 moves for a total of 13.85 (approximately). EOLR according to the above table is 13.47.

 

[Elo13]

So a worse movecount, more algs, and a recog pause half the time.

plus 3.75 to permute the midges (correct me if I'm wrong on that)

According to Arc's table it is around 4.8.

 

[pizo45]

BLockbuilding left right reduction method (BLRRM)

1. build a 1x2x3 intuitively on l
2. build solve the half cross that's on the d layer and the m slice while orientating the the edges
3. solve the rest of the cube with just R and U moves (sometimes u get parity, you can fix that by using commutatators)

example sovle coming soon

 

[Sue Doenim]

Looks just like Leor. Look in the 3x3 example solves thread to see.

 

[pizo45]

exaple solve BLRRM (blockbuilding left irght reduction method:

D2 r2 U' R' F
U R2 U r U' M U' M2
U R2 U R' U2 R U R' U' R2 U R' U R U R' U2 R U R'
U2 // alg

 

[Thom S.]

BLockbuilding left right reduction method (BLRRM)

1. build a 1x2x3 intuitively on l
2. build solve the half cross that's on the d layer and the m slice while orientating the the edges
3. solve the rest of the cube with just R and U moves (sometimes u get parity, you can fix that by using commutatators)

Pretty sure that has been proposed before.

In fact I'm even more sure I was one of those

 

[Teoidus]

BLockbuilding left right reduction method (BLRRM)

1. build a 1x2x3 intuitively on l
2. build solve the half cross that's on the d layer and the m slice while orientating the the edges
3. solve the rest of the cube with just R and U moves (sometimes u get parity, you can fix that by using commutatators)

example sovle coming soon

Er, that's not parity--corners being unsolved is an even permutation and is a perfectly reachable state on 3x3.
Your method is basically leor but fish&chips instead of ZBLL.

 

[Teoidus]

exaple solve BLRRM (blockbuilding left irght reduction method:

D2 r2 U' R' F
U R2 U r U' M U' M2
U R2 U R' U2 R U R' U' R2 U R' U R U R' U2 R U R'
U2 // alg

Where's the scramble..?

And you can use proper spelling/punctuation/capitalization please? We already have one lookadoo as is...