Q-M's LL skip method

[Q-M]

Early Christmas present for you, Speedsolving Forums.

I realise the title is a bit clickbaity, but it does what it says on the tin. This is a method which produces a forced LL skip every solve. Instead of orienting all edges beforehand and skipping LL with the last slot (`2,000 algorithms), or worse doing everything while inserting the last pair (>10,000 algorithms), we split up the task across multiple F2L pairs.

The four aspects of the last layer are edge orientation (EO), corner orientation (CO), edge permutation (EP), and corner permutation (CP). We must force skips on all four aspects to skip LL.

DISCLAIMER: This may not be a method appropriate for speedcubing, and the total move count (at least in my solves) seems a bit high. It is simply a novel, experimental, and practical method to skip the last layer by splitting up the above aspects among multiple F2L slots rather than just the LS. That being said, I have done my best to optimise these algorithms by hand.

there are three essential tenets of this method:
1. <R,U,L,D> algorithms preserve EO.
2. <R,U> algorithms preserve EO and CP.
3. <R,U2> algorithms preserve EO, CP, and CO.

The steps of the method are as follows:
1. Orient all edges vis-à-vis ZZ, and place the DF, DL, and DB cross edges.
2. Insert the first F2L pair in the BL slot
3. (2SCP) Place the DBR corner at DBR, not necessarily in the correct orientation. Insert the second F2L pair in the FL slot, simultaneously putting the remaining corners (and thus the cube) into the <R,U> subgroup, using one of 4 algorithms (4-6 moves).
4. (3SCO) Place the DR cross edge and any corner (apart from DBR) at DFR, oriented so that its L/R sticker faces right. Insert the third f2L pair in the BR slot, simultaneously orienting the remaining corners so that their L/R stickers are on the L/R faces, with one of 27 algorithms (4-11 moves). The corners are now in an <R,U2> subgroup (the edges aren't, but we'll get to that), and using <R,U2> to setup the last F2L pair forces either Winter Variation case #7 or #17 for the final pair.
5. (LSLL) Pair up the final F2L pair using <R,U2> moves (if the F2L edge is at UF or UB, use R'U'R'U'R'URURU or its inverse). Insert the final pair using one of 24 algorithms (4-16 moves) (12 EP cases × 2 WV cases) to permute edges.

Steps 1, 3, 4, and 5 force EO, CP, CO, and EP skips with 0, 4, 27, and 24 algorithms, for a total of 55 algorithms. Taken together, these lead to a forced LL skip. Algorithms for 3SCO and LSLL, as well as a tutorial and the 4 algorithms for 2SCP, are attached PDFs.

Let me know what you think!

Cheers,
QM

 

[AlexMaass]

example solves? seems interesting, but also complex as well, so I haven't read through it yet

interesting idea with doing the steps of the last layer or whatever each at the same time as each f2l pair (except eo cus zz lol)

example solve?

 

[sqAree]

I'd also be interested in an example solve, because I'm too lazy to make one by myself.

 

[Calode]

How about you just do Roux
Do first block
then place br corner, then do cp (6 algs, I have them genned)
then finish right block
then do ocll (7 algs)
then lse

Bam, "LL skip" method with 13 algs.

 

[AlexMaass]

How about you just do Roux
Do first block
then place br corner, then do cp (6 algs, I have them genned)
then finish right block
then do ocll (7 algs)
then lse

Bam, "LL skip" method with 13 algs.

kleb, doing roux is not ll skip you pleb

 

[Calode]

kleb, doing roux is not ll skip you pleb

neither is doing a million algs so that you don't have to do zbll/pll

You're also very specific about the order of f2l pairs which is bad. Good methods should give you lots of freedom.

 

[mDiPalma]

congratulations on compiling this procedure. i've never thought of orienting wrt LR while inserting a pair, especially not the penultimate pair.

don't let these guys diminish what you've done.

 

[Q-M]

example solves? seems interesting, but also complex as well, so I haven't read through it yet

interesting idea with doing the steps of the last layer or whatever each at the same time as each f2l pair (except eo cus zz lol)

example solve?

I'd also be interested in an example solve, because I'm too lazy to make one by myself.

Scramble: R D2 U2 L' F2 R B2 L' D2 L' F U' B F2 U F D' R' B' L'

Inspection: x2
EO: U' D F R' B R B' L' D' L'
1st pair: R2 U R' U' R L U' L'
2nd pair setup: U2 R U' L' U L.
The CP is (13)(245), which we reduce to the <R,U> permutation (13)(24) by transposing (45). This is done with the 2SCP insertion R'UR2U2L'UL.

For 3SCO, we place the cross edge using U'R'UR', then insert the UFL corner at 5 using U'RUR'. (This is one of the worst cross+corner cases possible.)

We setup the 3rd pair with UR'URU'R'UR. We insert with 3SCO algorithm
U2 R U R2 U R2 U2 R'

The LSLL case is one of the 12 "canceled-antisune" WV cases, solved with R'U'RURU'R'U'R'UR

How about you just do Roux
Do first block
then place br corner, then do cp (6 algs, I have them genned)
then finish right block
then do ocll (7 algs)
then lse

Bam, "LL skip" method with 13 algs.

I realise this is kind of a devil's advocate position, but frankly I don't see how even technically this qualifies as a LL skip method. ZZ-CT, I can understand, but the Roux method as you described leaves OCLL and the last six edges unsolved when the second block is completed.

The idea behind calling this a "LL skip method" is that, when F2L is completed, you don't have to do anything further to solve the last layer. I'm not sure it even makes sense to talk about a LL skip method based on Roux since leaving the M-slice available for use is one of its signatures. Don't get me wrong, Roux is cool - in my earlier stages of development I studied it as a possibility for EP - and the variant you described does indeed solve the cube with 13 algorithms (assuming intuitive LSE, which is kind of move-intensive).

neither is doing a million algs so that you don't have to do zbll/pll

Sorry, but... why exactly? I would understand if, like ZZ-e, the method requires an algorithm on its own. However, in my method everything apart from EO is done in conjunction with inserting an F2L pair, so I'm actually solving the last layer while solving F2L. After inserting the last pair according to this method, the entire LL is solved save for AUF at worst - which at least technically sounds like a LL skip. Of course it's not the most efficient method, but how exactly isn't it a last layer skip?

You're also very specific about the order of f2l pairs which is bad. Good methods should give you lots of freedom.

Truthfully I've been bothered by this too. It's pretty clear that in addition to BL-FL-BR-FR, we can interchange the order of the first two or last two pairs as long as the left block is completed before the right block. Mirroring the 2SCP cases is trivial, and the 3SCO/LSLL algorithms aren't much harder. I included descriptions for these algorithms to help both memorization and mirroring based on recognition of the pieces mid-algorithm.
We can also do the right block first using a wide d2 after EO. This avoids <L,U> which is uncomfortable for right-handed solvers. There's another way to do that - it's a bit of a stretch, but once the 2x2x3 block is completed, there are two ways to complete F2L:
1. Placing the DR edge and completing the two remaining pairs at BR and FR.
2. Place the UL edge and place two "F2L" pairs on the L face at UF and UB.
Thus, instead of doing the left F2L block first, we can just as well do the right F2L block, put the cube into <L,U>, rotate with z (transmuting to <R,U>), and complete F2L in this alternate way.

Thus in principle this method can trivially be extended to do the F2L pairs in 8 of the 24 cases. In fact, after locking in EO the only real requirement is that the first two F2L pairs are either both on the left or both on the right

congratulations on compiling this procedure. i've never thought of orienting wrt LR while inserting a pair, especially not the penultimate pair.

don't let these guys diminish what you've done.

3SCO is really the core of the whole method in my opinion. Thank you for the praise.

 

[shadowslice e]

stuff

Though in general I am not a fan of methods which require you to do something special in each small step, I am impressed with the ideas you have had, especially the second step which seems like it could easily be made viable if a relatively simple recognition method is made (at least compared to the methods for CP I have made) and I have no doubt that I will need to look into implementing it into some of my methods. Overall, very good job and a great (almost) introductory post!

 

[Smiles]

that solve was 66 HTM, is there any way that can be decreased?
it seems like it took around 20 moves to insert the 3rd pair, but you did say it was the worst case

 

[Q-M]

that solve was 66 HTM, is there any way that can be decreased?
it seems like it took around 20 moves to insert the 3rd pair, but you did say it was the worst case

There are several ways I'm looking at improving this. Unfortunately it seems like all of them involve more algs, but I'm willing to take that hit knowing my first implementation skips LL with fewer algorithms than CFOP OLL.

First F2L pair: Frankly, doing nothing in conjunction with the first pair sticks in my craw, but there's not a whole lot one can do at this point. It's too early to force an <R,U> CP (although it's likely possible to influence it). The most viable option I've come up with to save on moves here is to do multislotting so that the FL pair is set up after inserting the BL pair (n.b. yes, F/B and R/L can be exchanged so long as one of the two is F and the other is B).

2SCP: Getting rid of that DBR placement is the most tempting reduction IMHO. Instead of 20/120 good/total CP cases, we now have 120/720, but my approach to CP doesn't involve memorising bad cases. It's all about knowing how applying transpositions changes a permutation, albeit kind of dependent on maths and permutation groups. But the algorithms are frankly a cakewalk. The obstacle here is learning to recognise 120 "good" CP cases, so that when one of the 600 bad cases comes along we know how to reduce it to a good case in a single transposition. Since I've already got the 20 cases where 6 is fixed, a nice way to equipartition the rest is into cases which map 6->1, 6->2, 6->3, 6->4, and 6->5. If you're interested, these CPs can be obtained from those which fix 6 by applying (3654), (35)(46), (3456), (3456)(1432), and (3456)(13)(24) to all 20 (generating cosets of these 5 permutations by the set of 20 CPs fixing 6). Modern algebra FTW!

Another idea I was toying with here is to do some kind of WV/phasing while inserting with <L,U> (doesn't affect CP) to induce partial CO control. This reduces the number of moves required to insert the edge and corner before the 3rd slot, although...

3SCO: I hate having to place a correctly oriented corner at DFR along with the edge. It feels like I'm doing the same work as inserting an extra F2L pair just placing them, especially since the edge alone can be placed in 0 (1/7), 1 (3/7), or 2 (3/7) moves. If 3SCO is done without an oriented DFR edge, then the number of cases (and algorithms) goes up from 27 to 81. I think this is worthwhile considering it can save about 6-7 setup moves and, based on the ~20 or so I've generated, many of these algorithms are <9 moves long.

LSLL: There's not terribly much to do here, to be honest. Some of the <R,U2> setup moves are a bit long and I've generated them with Cube Explorer (some tricks applied in terms of undefined cubies and truncating algorithms before U2RU2R'), but it's more memorisation and frankly I find the lengthy <R,U2> setups easier in most cases. The reason is you can just "jump in" to RU2R'U2RU2R'U2... at either R or the first U2, and keep going until the pair is setup for insertion at FR. Unless the corner is at UFR and the edge at FR, the corner is at UFL and the edge at UL, or the edge is at UF/UB (hence cannot be placed with <R,U2>), this is basically what I do.
------------------------------------------------------------
Anyway, I reiterate my disclaimer from earlier - the method may not be suitable for speedcubing, but that's fine with me. It's a proof-of-concept for a viable last layer skip method, and it does indeed work, however inefficient (I've done ~200 solves with it since finishing development).

Cheers,
QM

 

[Teoidus]

There are several ways I'm looking at improving this. Unfortunately it seems like all of them involve more algs, but I'm willing to take that hit knowing my first implementation skips LL with fewer algorithms than CFOP OLL.

First F2L pair: Frankly, doing nothing in conjunction with the first pair sticks in my craw, but there's not a whole lot one can do at this point. It's too early to force an <R,U> CP (although it's likely possible to influence it). The most viable option I've come up with to save on moves here is to do multislotting so that the FL pair is set up after inserting the BL pair (n.b. yes, F/B and R/L can be exchanged so long as one of the two is F and the other is B).

Maybe you could allow for the first step to keep 2-4 edges badly oriented, and then use an alternative insert during first pair to fix them, completing EO? I'm not sure this would be always better, but it would be one way to make use of the first pair insert

 

[Q-M]

Hey it's its own thread again!

Maybe you could allow for the first step to keep 2-4 edges badly oriented, and then use an alternative insert during first pair to fix them, completing EO? I'm not sure this would be always better, but it would be one way to make use of the first pair insert

So I've been giving this a bit of a think. Here's what I came up with for 1SEO possibilities:

The method as it stands: EO first. The subject of my current lament.

Approach 1: Place the DF, DB, and DR cross edges (pseudo-cross). Then their edges are solved, hence oriented. This leaves at most 9 bad edges - meaning at most 8 bad edges thanks to EO parity. If we fix one oriented edge, then there are 2^8 = 256 possible cases. Some of these might be reduced to a "canonical form" via <R>, <R>U'<R>U (assuming WLOG insertion in the BL slot), and so forth. I don't think it's worth pursuing this approach - Even if the number can be reduced from 256, it probably can't be reduced by much.

Approach 2: Orient all but 2 of the edges before doing the pseudo-cross. Place the bad edges at BL and UB, then sledgehammer. This works, but doesn't seem worth it - placing the edges takes a significant amount of effort.

Hmm... Isn't there a system for orienting edges while inserting an F2L pair (albeit the last one)?

Approach 3: Orient all but 2 or 4 of the edges before doing the pseudo-cross. Place the bad edges at BL and in the U layer. Use VHLS to place the edges (16 cases counting both orientations of the F2L edge). This could work, but there's a bit of a problem when lots of bad edges are "stuck" out of U and BL.

Approach 4: Same as 3, but orient all the bad edges wherever they are (modulo, say, <R>). This looks like a lot of algorithms. Without the <R> equivalence, there are 9*8/2=36 cases with 2 misoriented edges and 9*8*7*6/24=126 cases with 4 misoriented edges. This doesn't seem worthwhile.

Approach 5: Same as 3, but instead of placing the bad edges at BL and in the U layer, if an edge is stuck in FL, place another bad edge at UF and do a sledgehammer.

Approach 6: The idea is to transport bad edges around via <R,U,L>, so that bad edges stay bad and good edges stay good. All the while we can use sledgehammer to orient pairs of bad edges. Stop when a VHLS case is reached, and then do VHLS.

Honestly, I think approach 6 is the best of the lot, but I'm still not sure. The ZZ approach to EOLine reportedly takes a maximum of 9 moves, and the last cross edge takes at most 3 moves and an average of 1.8 (0.1*0+0.3*1+0.3*2+0.3*3). Doing 1SEO is advantageous only if pre-EO + pseudocross + the EO bit of the first slot, combined, is less than this, and while this happens from time to time I don't think it's very likely. Granted, it may be worth it to recognise the "one F/F' and/or B/B' orients all but 2 edges" cases - 1SEO makes some sense for these - but there's not much else. There's also the recognition penalty - spotting misoriented edges in one look and then identifying the remaining ones in another is difficult - recognition is hard as it is, and only really worth it during inspection.

My conclusion is that doing EO from the start is best except in a very finite number of circumstances. (Change my view? I'd honestly prefer to be wrong about this.)

I'm actually facing a similar recognition problem with CP. I feel like the mechanics of this step are pretty good, but even identifying the CP takes a lot of work since you either need to see all three stickers of each corner, or two of the three with a deep enough understanding of the colour scheme of your cube to deduce the third colour without seeing it.

Cheers,
QM

 

[Teoidus]

Hmm. Yeah, it does seem like leaving EO for first slot just seems to complicate things. Perhaps just make it so that, instead of always going for a cross, you try and blockbuild up to the 2x2x2 in BDL + DF edge? So in certain situations, it might be more advantageous to solve a square in the back, then extend to a 2x2x2 and then place DF. Then you could carry on as normal with the 2nd, 3rd, and 4th slots, but on top of a more efficient start.

As far as CP goes--recently I posted something in the substep thread about a means of detecting and fixing that stuff in inspection. I'm not sure if it'll be totally relevant for you since you have CP being solved a little bit later down the line and it's meant to work for methods that tackle CP before anything else, but it could be worth giving it a look. It also seems like you know a good bit of group theory, so it'd be nice to get the thoughts of someone who has that mathematical background.

 

[efattah]

I admit I am not a CFOP specialist, but although I like Q-M's general idea, I think we would need to change the implementation to make it viable for speed solving.

My approach to a similar method would much simpler:
- For each F2L pair you identify, instead of having around 40-50 F2L 'algorithms' to make the pair (and then two choices on how to insert it), I would increase this to say triple that number
- The idea is to not just orient the LL edges during F2L (as ZBLL solvers do), but also to orient LL corners, and if you are okay with memorizing even more algorithms, possibly permuting the corners as well
- Using this method you would end up with an OLL skip, and on some solves you will be able to essentially execute OLLCP during F2L, meaning you get an EPLL, which would be an LL skip 1 in 4 solves

 

[sqAree]

EPLL skips only 1 in 12 solves.

 

[Calode]

Sorry, but... why exactly? I would understand if, like ZZ-e, the method requires an algorithm on its own. However, in my method everything apart from EO is done in conjunction with inserting an F2L pair, so I'm actually solving the last layer while solving F2L. After inserting the last pair according to this method, the entire LL is solved save for AUF at worst - which at least technically sounds like a LL skip. Of course it's not the most efficient method, but how exactly isn't it a last layer skip?

You're still having to do all the parts to LL: co, cp, eo, ep, but you do them all separately in the wrong parts of the solve. You're just moving the parts of LL into F2L.

Would you consider Roux a LL skip method? It does exactly this but with fewer algs and better flow overall.

 

[mDiPalma]

You're still having to do all the parts to LL: co, cp, eo, ep, but you do them all separately in the wrong parts of the solve. You're just moving the parts of LL into F2L.

Would you consider Roux a LL skip method? It does exactly this but with fewer algs and better flow overall.

Roux is not at all an LL-skip method, and anyone who says so is dumb. If a Rubik's Cube has 3 layers, the M-slice is the "Last Layer" of Roux. Can't you see that?


The method proposed in this thread in an exercise in segregating and solving the characteristics of the cube procedurally during the F2L.

The way I see it, there are 5 characteristics to the cube: EO, EP, CO, CP, and "compatibility" (meaning the EP and the CP are solved wrt each other).

This method solves EO in the beginning, CP at the second pair, CO (wrt R/L) during the third pair, and EP + "compatibility" during the last pair. I don't think there's a better way to do it.

This method is a true LL-skip method. That is, the LL is solved at the same time that the other layers become solved, apart from an AUF.

 

[Q-M]

I admit I am not a CFOP specialist, but although I like Q-M's general idea, I think we would need to change the implementation to make it viable for speed solving.

My approach to a similar method would much simpler:
- For each F2L pair you identify, instead of having around 40-50 F2L 'algorithms' to make the pair (and then two choices on how to insert it), I would increase this to say triple that number
- The idea is to not just orient the LL edges during F2L (as ZBLL solvers do), but also to orient LL corners, and if you are okay with memorizing even more algorithms, possibly permuting the corners as well
- Using this method you would end up with an OLL skip, and on some solves you will be able to essentially execute OLLCP during F2L, meaning you get an EPLL, which would be an LL skip 1 in 4 solves

- LL corners, once oriented, can be misoriented with <R,U>; however, CP is preserved. This is why I decided to do CP with the insertion of the 2nd pair.
- If you want to orient everything and permute corners during F2L (basically CP*OLS), you would need 6(CP)*432(OLS)=2592 algs. You could split up some of these steps across multiple F2L pairs, but I've already done that for you...
- As previously mentioned, the probability of an EPLL skip is 1/12. If an OLLCP skip is enough for you, I propose the following: Follow my method through 2SCP, insert the 3rd pair normally, and insert the 4th pair with 2-gen WV (27 algs, I have them genned). OLLCP skip, and LL skips with probability 1/12.

You're still having to do all the parts to LL: co, cp, eo, ep, but you do them all separately in the wrong parts of the solve. You're just moving the parts of LL into F2L.

I actually don't disagree with any part of this except for the word "wrong." For my purposes, I consider them the "right" parts of the solve to do them because the steps of LL are done as early in the solve as is "practical." EO is done right from the beginning, CP is "solved" by the time it is possible to 2-gen the remainder of the cube, and CO is done upon insertion of the 3rd pair so it doesn't have to be done together with EP (which as far as I can tell cannot be practically solved before the final pair).

There is a 72-algorithm approach to do EP and CO together in the last slot, which may be the best value for algorithm count in terms of doing two LL steps in one F2L slot. But this didn't seem as "elegant" to me.

To my knowledge, there is no way to force-skip EO, CP, CO, EP, OLL, PLL, etc. without doing something, somewhere. I'm not claiming a method that gives you a 1/15,552 lucky LL skip every single time, I'm presenting a way to produce a forced LL skip with no luck needed, 1/1 of the time.

Oh, one more thing, sir:

You're just moving the parts of LL into F2L.

I'm afraid I must take that as a compliment.

The method proposed in this thread in an exercise in segregating and solving the characteristics of the cube procedurally during the F2L.

The way I see it, there are 5 characteristics to the cube: EO, EP, CO, CP, and "compatibility" (meaning the EP and the CP are solved wrt each other).

This method solves EO in the beginning, CP at the second pair, CO (wrt R/L) during the third pair, and EP + "compatibility" during the last pair. I don't think there's a better way to do it.

This method is a true LL-skip method. That is, the LL is solved at the same time that the other layers become solved, apart from an AUF.

Thank you. I appreciate the vindication.

 

[OreKehStrah]

This is a very neat method and it's a shame it didn't get much recognition or further development. Here's an example solve:

U' B U R2 U2 D L' D' R2 U' R2 U2 R2 D' R2 F2 D2 R2 F2

yz2 // inspection
F2 L2 U' F L' U' F2 U L' U R2 // EOCross plus one
U' R' U R // 2SCP a
U2 R U' R' U L' U2 L U // 2SCP b
U R U2 L' U L R' // 2SCP c
R' U' R U2 R' U2 R U' // 3SCO a
U2 R' U2 R U' R U R' U' // 3SCO b
U2 R U2 R' // LSLL a
R' U' R' U' R U R U R2 U R' U' R U' R' // LSLL b
U' // AUF

68 STM
----------- EDIT -------

One of the ides I've had towards developing this further is the use of influencing, using a z rotation for more RU turning, and solving 2 D layer corners for greatly improved CP recog. An example as follows:

U R' U R D' L' F' D2 R2 D2 F2 L' U2 D2 B2 L U2 L F'

y U R L B U2 D' F' // EOLine
L' R2 U2 R2 // BR Square
L' R U2' R' U L U' L2 // From FR + dL Corners
U' R2 D R' U' R D' R2 // 2SCP
z // Now we have 2Gen Finish
R2 U R2' U R2 // Form 2nd BR Pair + Solve 2nd DR edge
U2 R2 U' R U' R2 U R2 U R2// 3SCO CO is relative to the L/R faces
// Lol this skipped forming 2nd FR Pair
U2 R' U' R U R U' R' U' R' U R // LSLL

The only thing about this is that the placement of the D layer corners improves CP recog but does not contribute to the solve otherwise. It would be cool if the method could be developed to solve around having these pieces placed so that placing them helps CP recog AND futhers the solve.