# CFOP efficiency and multi-slotting



## mark49152 (Dec 10, 2013)

There seem to be so many different LL and LS options and so much effort has been invested in devising and learning these, with new proposals emerging on almost a weekly basis. Yet, relatively little seems to have been invested in improving F2L, which is the longest and least efficient aspect of a CFOP solve. I have been wondering why that is the case, and what the potential is for improving the efficiency of F2L.

Cross is typically close to optimal and takes on average ~1.5 moves per piece solved. This is with no solved pieces to preserve, so maximum freedom to turn the cube without breaking anything.

At first I thought that steps that have to preserve more solved pieces would be less move-efficient, but that seems not to be the case (at least not until only 3-4 pieces remain). For example, optimal 1LLL has to preserve 12 solved pieces, but still takes on average ~1.6 moves per piece to solve the remaining 8 pieces. Running Cube Explorer to find a few optimal solutions for solving F2L pairs (solving 8 pieces, preserving 4 in the cross) typically found solutions in the 13-14 move range, so again ~1.7 moves per piece. Both of those are surprisingly close to cross efficiency. 

What does seem to impact efficiency is the number of pieces solved in the step. Using Cube Explorer on the same examples that gave 13-14 move F2L solutions found optimal solutions of 9-10 moves to solve just the front two pairs, or ~2.4 moves/piece. And according to the wiki, the average optimal solution for one F2L slot = 6.7, or 3.35 moves/piece. 

So, steps that solve a small number of pieces are generally less move-efficient. F2L is inefficient because it breaks down into four sub-steps solving two pieces each. A typical non-optimal human F2L solution is 29 moves or ~3.6 moves/piece. This is the primary reason for the high move count of CFOP. OLL/PLL work out at only ~2.8 moves/piece.

(This realization has helped me see the genius in Roux: the first two steps are broken into groups of 5 pieces each, enabling more move-efficient solutions. Second block optimal solutions seem to be in the range 8-10, or ~1.8 moves/piece, so the potential for improving efficiency is much greater than is allowed by optimal CFOP pairs. Not only that, but L6E does not have to be concerned with preserving corners or the other four edges, so can be more move-efficient while remaining intuitive.)

Staying on topic with CFOP, I started looking into multi-slotting to see if it holds potential for improving F2L efficiency. Surprisingly there are very few resources on this, so I assume it is rarely used. (Multi-slotting refers to using the insertion of one pair to help the setup of the next pair.) 

I found two main resources. The page at http://f2l.net46.net/multislotting.html gives 8 different inserts and lists 80 cases where setup of the next pair is achieved by one of these insertions. The files at http://absolutemind.pagesperso-orange.fr/ms-angl.html on the other hand list 150 possible cases and give individual solutions for these, but are incomplete. Both of these resources ignore the back two slots. If the back two slots are accounted for, there are 245 cases for each of RUR’ and RU’R’ setup pairs (I suspect there are some mirrors in there but am not smart enough to work them out). Too many to learn in its entirety, but as the first page indicates, there are some simple techniques that can be applied to many cases, perhaps intuitively.

In theory, if multi-slotting could be useful in ~50% of cases, when setting up the last three pairs, and if in each case it eliminates 3 moves from the setup of the next pair without adding additional moves to the insertion, that’s an average saving of 4.5 moves/solve reducing typical F2L pairs to 24.5 moves or ~3.1 moves/piece. So multi-slotting is not a holy grail, just an interesting idea that given the inefficiency of F2L, might be worthy of further development.

Does anyone here use multi-slotting or have thoughts on its potential? Any pointers to other resources or discussions on improving F2L efficiency by merging solutions for pairs would also be appreciated. Otherwise I might just have to learn to block build .


----------



## teller (Dec 10, 2013)

I think multi-slotting will be a huge breakthrough at some point in the future. But it presently presents a wall...once you start combining pairs, the amount of variety is ridiculous (not even considering some new avenues that have opened up recently like using the D layer more aggressively). There aren't many resources because no one has discovered a clear strategy that can be broadly applied. Longs lists of algs for R U R' is a start, but those really aren't the droids you're looking for. I suspect that many elite cubers have deep-enough look-ahead that they achieve some multi-slotting intuitively, but when I see the reconstructions it's rarely there.

Sorry that I have nothing to offer, but I agree that there's gold to be found here.


----------



## Escher (Dec 10, 2013)

teller said:


> There aren't many resources because no one has discovered a clear strategy that can be broadly applied.



This is definitely the problem. I've been thinking for a long, long time (maybe 2 years) about writing something to do with multi-slotting, but every time I begin writing I end up hitting a bit of a road-block. I don't know whether this is due a lack of explanatory powers on my part or I'm just missing the terminology to concisely describe it - perhaps I'm just missing the point. 

Anyway, it becomes easier and easier the more experience you have with f2l and I would say I'm now consistently able to produce 24-27 move f2l solutions that are just a mix from my bag of tricks that individually aren't hard to understand. Basically, you need reasonably deep look-ahead (not as far as you'd think) and the ability to understand what your pair solutions do to priority pieces on the cube, and identifying those priority pieces isn't too complex a heuristic but there's definitely quite a bit of 'feel' involved. Pair selection and multi-slotting go hand in hand and I think pair selection is easier to understand and implement at first. 

I would say pair selection can be well-implemented even with only 1 way of solving each f2l case (and this might be something I can explore for trying to write an article about it). Multi-slotting then, becomes a by-product of good pair selection along with having multiple options to solve pairs. I don't think the way that the pasperso pages describe multi-slotting is really hitting the mark and I actually think that they're quite misleading as to what multi-slotting means. It's more of a thought process or selection of choices rather than anything you can reasonably delineate with algorithms.

I'll try to give you an example solve and stop being so cryptic, but bear with me - sometimes it's hard to say 'why' you should do something when it's non-verbally learned as 'just better':

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

z2 F2 U' R' F U L' (6)

This places the formed pair on the U layer and releases what would be a trapped corner (look at the UBL piece before doing the final U L'), while only adding 1 move to the optimal cross solution here.

y R' U2 R (9)

This hides our released corner preserving it's position (it currently has a good relation to its edge). We could do U R' U R which is okay too, but our plan was to solve the FR pair next and it's preferable to stick to preserving that - it makes checking for our next pairs a little simpler. Also, consider how nice the next case will be AFTER that one given our current plan...

y' R U R2 U' R (14)

This conveniently joins up our FR pair while solving our BR. Although in a 1-slot left case that FR pair would be bad, it's good to be aware of how empty slots can help you develop pieces before you insert them.

U F R' F' R (19)

Simple trick to preserve the position of the corner but flip the orientation of the edge, giving us a nice 3 move insert.

y' U' R U R' (23)

I'd like to provide more but I'm a little hungover and this takes a reasonable amount of effort to transcribe - perhaps if I can locate a camera a short video might be better.


Btw, in regards to your numbers for the typical human non-optimal f2l solution (29) - I assume that doesn't include cross, because my guess for the average cross + f2l incidentally is 35.


----------



## Bunyanderman (Dec 10, 2013)

http://absolutemind.pagesperso-orange.fr/msd-angl.html


----------



## windhero (Dec 10, 2013)

Most of the algs here http://f2l.net46.net/multislotting.html are just what I and many others would do intuitively. It doesnt exactly count as multislot imo, it kinda breaks lookahead down to 2 pairs instead of 4. F2L should be free to solve whatever pops in front of you first. The true benefit of multislotting comes from diagonal multislotting, not adjacent. If 2 adjacent slots are solved chances are your empty slots are on the front side and that lookahead is ridiculously easy.


----------



## ILMZS20 (Dec 10, 2013)

well multi slotting will probably be more efficient but look ahead would be alot harder i think. if you really use multi slotting then your tps will definitely go down because you need much, much more look ahead and i guess it would be better to just simplify your solves instead of doing stuff you actually have to think about that much. so i think that this would be more efficient but still slower, but i dont have too much of a clue so i might be wrong.


----------



## Renslay (Dec 10, 2013)

Why not blockbuilding?


----------



## TDM (Dec 10, 2013)

Personally, I've never liked the inefficiency of standard CFOP. Whilst I understand solving a cross makes lookahead easier and is something you can continue on with from the beginner's method so you don't have to learn anything new, I can't see any advantage to solving a cross when all you have to do to complete the F2L is break it, re-solve it, break it, re-solve it, and then do that for another three F2L pairs. It really isn't efficient. I like the idea of multislotting though, as it means you don't have to break and solve the cross as much as in a solve without multislotting. I've been thinking of switching to another method where you don't solve some pieces and then unsolve and then solve them again all the time, but as I'm more experienced with CFOP, I think I'll practise multislotting and see how I find it.


----------



## Dapianokid (Dec 10, 2013)

I use multislotting. I believe Petrus and Roux to be more efficient ways of solving, but harder to learn with the same mastery and maturity as one can learn CFOP in the same amount of time with the same amount of practice. Because of the freedom, picking up tricks and learning hows and whys to the things you do take much longer because of the distance between solves that incorperate the same newly learned technique. CFOP is so beautiful to me because it isn't as highly intuitve as others, and we can learn to master it better and improve upon it. I believe if one focused on one substep of Petrus or Roux for a while, they might gain some level of mastery similar to that which one achieves when using CFOP for so long. I mean, building pairs optimally and easily and with sexy movements comes so naturally to an experienced CFOP solver. But building a 2x2x3 block takes time and thought.

For those who tl;dr'd,

He basically asked about how to improve this method's primarily longest stage: F2L, and the effectiveness of multislotting. Moral of the story: Efficiency in CFOP takes off .5 of a move per piece of F2L, a total of 4 extra moves. When they are finger-friendy, it takes me about as long as it takes me to open my eyes and close them again as quickly as possible to do 4 moves, so I don't feel as if I'm wasting much time by being a little bit less efficient and more focused on finger-friendly movements.


----------



## rj (Dec 10, 2013)

Renslay said:


> Why not blockbuilding?



Freefop, and I use it. It's fun. It works.


----------



## Lchu613 (Dec 11, 2013)

Dapianokid said:


> I use multislotting. I believe Petrus and Roux to be more efficient ways of solving, but harder to learn with the same mastery and maturity as one can learn CFOP in the same amount of time with the same amount of practice. Because of the freedom, picking up tricks and learning hows and whys to the things you do take much longer because of the distance between solves that incorperate the same newly learned technique. CFOP is so beautiful to me because it isn't as highly intuitve as others, and we can learn to master it better and improve upon it. I believe if one focused on one substep of Petrus or Roux for a while, they might gain some level of mastery similar to that which one achieves when using CFOP for so long. I mean, building pairs optimally and easily and with sexy movements comes so naturally to an experienced CFOP solver. But building a 2x2x3 block takes time and thought.
> 
> *For those who tl;dr'd,*
> 
> He basically asked about how to improve this method's primarily longest stage: F2L, and the effectiveness of multislotting. Moral of the story: Efficiency in CFOP takes off .5 of a move per piece of F2L, a total of 4 extra moves. When they are finger-friendy, it takes me about as long as it takes me to open my eyes and close them again as quickly as possible to do 4 moves, so I don't feel as if I'm wasting much time by being a little bit less efficient and more focused on finger-friendly movements.




I'm sorry but I almost tl;dr'ed on both walls, despite the second wall being shorter.

Don't worry though I actually decided to read both.


----------



## evogler (Dec 11, 2013)

mark49152, I'm trying to PM you but it says your inbox is full.


----------



## Arkwell (Dec 11, 2013)

Doesn't Feliks use some multi-slotting? Or is it that his lookahead is so good that it just looks like multi-slotting?(Been checking some Feliks reconstructions)


----------



## uberCuber (Dec 11, 2013)

Arkwell said:


> Doesn't Feliks use some multi-slotting? Or is it that his lookahead is so good that it just looks like multi-slotting?(Been checking some Feliks reconstructions)



Read Escher's post on the first page. Those two concepts kinda merge together.


----------



## elrog (Dec 11, 2013)

This doesn't have anything to do with multislotting and it doesn't really help, but its fun to mess around with. I was as well thinking of a way to make F2L better (but not entirely in terms of move efficiency). I was thinking that it would be alot easier to choose the best F2L pair to do and it would be easier to look ahead if more F2L pieces were in the top layer. This would also allow you to actually use the 42 F2L algorithms which never were very useful because you mostly get cases where your pieces are in other slots. So what I did was fill the F2L slots with the 8 top layer pieces and then did my F2L. This makes the look ahead extremely easy, but it was then that I realized this restricted you from using empty slots without canceling out the work you already did. I do, however, think that it would be feasible and could help to try and get 1 or 2 slots filled with top layer pieces while you make your cross.


----------



## rj (Dec 11, 2013)

elrog said:


> This doesn't have anything to do with multislotting and it doesn't really help, but its fun to mess around with. I was as well thinking of a way to make F2L better (but not entirely in terms of move efficiency). I was thinking that it would be alot easier to choose the best F2L pair to do and it would be easier to look ahead if more F2L pieces were in the top layer. This would also allow you to actually use the 42 F2L algorithms which never were very useful because you mostly get cases where your pieces are in other slots. So what I did was fill the F2L slots with the 8 top layer pieces and then did my F2L. This makes the look ahead extremely easy, but it was then that I realized this restricted you from using empty slots without canceling out the work you already did. I do, however, think that it would be feasible and could help to try and get 1 or 2 slots filled with top layer pieces while you make your cross.



This is a good idea. I will try this.


----------



## ianliu64 (Dec 11, 2013)

Bleh.
Multislotting isn't my thing.


----------



## ncube (Dec 11, 2013)

I think it could be a good idea to memorize how solving standard f2l cases affects the other corners and edges. Then instead of tracking a pair, one would be able to predict where it would be and I think this would allow for much, much better lookahead and allow faster tps. I think just from practice, many people already do this a bit. But, I think it could be pretty hard to memorize how exactly each f2l case affects others and so it's not really feasible.


----------



## mark49152 (Dec 12, 2013)

Dapianokid said:


> For those who tl;dr'd, .... Moral of the story: etc.


OK good point, it was rather long. For those who TL;DR'ed, here's the moral of my story:-

Optimal CFOP pairs done one at a time takes average ~3.35 moves per piece solved.
Optimal Roux blockbuilding takes ~1.8 moves per piece.
Multislotting won't realistically reduce the CFOP average much below about ~3 moves/piece.

All of which leads to the question, can multislotting or F2L in general be improved or developed further, to break this barrier? Perhaps the result would be a sort of hybrid, retaining much of the simplicity of F2L while gaining some blockbuilding characteristics and efficiency. Assume that ultimately, with mastery, move efficiency doesn't necessarily mean lower TPS.



teller said:


> There aren't many resources because no one has discovered a clear strategy that can be broadly applied.


Yes that's the impression I got. As Escher explained well (thanks for that and the helpful walkthrough!), multislotting seems to be an extension of lookahead to intuitively do some advance work on the next pair rather than just track it. That sounds like a natural progression, but if the expected saving is only 4-5 moves and yet it requires a level of lookahead and cube-awareness approaching that needed to do efficient blockbuilding, the effort is probably better spent on the latter.



Escher said:


> I don't think the way that the pasperso pages describe multi-slotting is really hitting the mark and I actually think that they're quite misleading as to what multi-slotting means. It's more of a thought process or selection of choices rather than anything you can reasonably delineate with algorithms.


I prefer the Absolute F2L resource. Although it looks like an alg list and, as you say, it's probably not reasonable to try to learn these as algorithms, I like the idea of studying a small selection of alternative inserts and what they do to other pieces, and Absolute F2L is better organised than Pagesperso for that.



windhero said:


> The true benefit of multislotting comes from diagonal multislotting, not adjacent.


I think only the RUR' cases are affected, but yes it would be good to see some L(...)L' options added to that list for when the BL slot is open. If I understood you correctly, which maybe I didn't... 



TDM said:


> I can't see any advantage to solving a cross when all you have to do to complete the F2L is break it, re-solve it, break it, re-solve it, and then do that for another three F2L pairs. It really isn't efficient.


Not sure I agree with that. It's a popular viewpoint, probably because it seems intuitive and Petrus said it, but if you fire up Cube Explorer and look at the optimal solutions for any of these stages they pretty much break apart everything and put it back together. What makes CFOP inefficient is not the cross, it's that in each step you are only solving two pieces at a time, and missing the opportunity to use all those turns to do something else useful as well.


----------



## Lchu613 (Dec 12, 2013)

elrog said:


> This doesn't have anything to do with multislotting and it doesn't really help, but its fun to mess around with. I was as well thinking of a way to make F2L better (but not entirely in terms of move efficiency). I was thinking that it would be a lot easier to choose the best F2L pair to do and it would be easier to look ahead if more F2L pieces were in the top layer. This would also allow you to actually use the 42 F2L algorithms which never were very useful because you mostly get cases where your pieces are in other slots. So what I did was fill the F2L slots with the 8 top layer pieces and then did my F2L. This makes the look ahead extremely easy, but it was then that I realized this restricted you from using empty slots without canceling out the work you already did. I do, however, think that it would be feasible and could help to try and get 1 or 2 slots filled with top layer pieces while you make your cross.



Meh. 
1. Algorithmic F2L. No. No.
2. Wasting moves beforehand that don't do that much
3. What's wrong with pieces in slots? Makes for a lot of really nicely fingertrickable F2L cases. 

All in all a good concept based on, imo, a skewed idea.


----------



## Bunyanderman (Dec 12, 2013)

mark49152 said:


> OK good point, it was rather long. For those who TL;DR'ed, here's the moral of my story:-
> 
> Optimal CFOP pairs done one at a time takes average ~3.35 moves per piece solved.
> *[*]Optimal Roux blockbuilding takes ~1.8 moves per piece.*




That is if you count a M slice move as 1 move, which it isn't, it counts as 2.


----------



## elrog (Dec 12, 2013)

Don't even go there.... All that really matters is how long the sequence of moves takes to perform, not the amount of moves it takes.


----------



## Bunyanderman (Dec 12, 2013)

elrog said:


> Don't even go there.... All that really matters is how long the sequence of moves takes to perform, not the amount of moves it takes.


But that is the main reason the move count looks so low. If you try to split apart a method to solve the cube as fast as possible mathematically, then you should play it by the books. IMO


----------



## mark49152 (Dec 12, 2013)

Bunyanderman said:


> That is if you count a M slice move as 1 move, which it isn't, it counts as 2.


No. I used the same Cube Explorer configuration and same 10 examples. Slice moves were disabled. It's only a small sample set, but then these are only rough numbers.

Edit: Having said that, I should have allowed slice moves for both Roux and CFOP, since that's how they would be executed in practice. But I'm still happy that the above is a fair comparison since both are the same metric.


----------



## brian724080 (Dec 12, 2013)

mark49152 said:


> Optimal CFOP pairs done one at a time takes average ~3.35 moves per piece solved.
> Optimal Roux blockbuilding takes ~1.8 moves per piece.
> Multislotting won't realistically reduce the CFOP average much below about ~3 moves/piece.



What's the number for ZZ?


----------



## mark49152 (Dec 12, 2013)

brian724080 said:


> What's the number for ZZ?


Good question, I don't know. I didn't measure it because I think of ZZ as a method designed to reduce rotations rather than move count. It would also depend of course on whether you complete F2L by blockbuilding or CE pairs. I'd hazard a guess that a similar factor of difference would be seen between those.


----------



## Escher (Dec 12, 2013)

Bunyanderman said:


> That is if you count a M slice move as 1 move, which it isn't, it counts as 2.



Why is it two? I just performed it on my cube at home and it felt a lot like 1 move.


----------



## stoic (Dec 12, 2013)

Escher said:


> Why is it two? I just performed it on my cube at home and it felt a lot like 1 move.



Are you sure you did it right?


----------



## Escher (Dec 12, 2013)

ellwd said:


> Are you sure you did it right?



I don't know, I performed it with a loose adaptation of this.


----------



## kunparekh18 (Dec 13, 2013)

Escher said:


> Why is it two? I just performed it on my cube at home and it felt a lot like 1 move.



Because WCA :/


----------



## mark49152 (Dec 13, 2013)

kunparekh18 said:


> Because WCA :/


To reiterate, and get back on topic, all the move counts in the analysis above are HTM, not STM.


----------



## Kirjava (Dec 13, 2013)

Bunyanderman said:


> But that is the main reason the move count looks so low. If you try to split apart a method to solve the cube as fast as possible mathematically, then you should play it by the books. IMO



What you're really just saying is we should play it by one specific set of books instead of another set of equally valid books because you personally prefer them.

What you are suggesting would make the comparison less meaningful.



mark49152 said:


> To reiterate, and get back on topic, all the move counts in the analysis above are HTM, not STM.



What idiot uses HTM as a speedsolving quantifier metric?


----------



## mark49152 (Dec 13, 2013)

Kirjava said:


> What you're really just saying is we should play it by one specific set of books instead of another set of *equally valid* books
> .....
> What idiot uses HTM as a speedsolving quantifier metric?


So, is it valid or not?

The reason I used HTM is that slice moves slow down Cube Explorer, and as I already acknowledged in a post above, "I should have allowed slice moves for both Roux and CFOP, since that's how they would be executed in practice. But I'm still happy that the above is a fair comparison since both are the same metric." The comparison isn't going to be turned on its head by redoing it all in STM, so I'm not inclined to spend time on it. 

Besides, move counts of optimal solutions aren't exactly a great "speedsolving quantifier", regardless of metric.


----------



## Kirjava (Dec 14, 2013)

mark49152 said:


> So, is it valid or not?



I'm saying that he seems to think that HTM is the One True Metric™ and you cannot correctly consider M a single move, but either view can be considered correct.



mark49152 said:


> The reason I used HTM is that slice moves slow down Cube Explorer, and as I already acknowledged in a post above, "I should have allowed slice moves for both Roux and CFOP, since that's how they would be executed in practice. But I'm still happy that the above is a fair comparison since both are the same metric." The comparison isn't going to be turned on its head by redoing it all in STM, so I'm not inclined to spend time on it.



You're right, it won't be that much different. I just wanted it to be known that STM would be a better alternative for this situation.

However! As good as STM is we all know ETM is better, but since this is hard to quantify we should fall back on STM.

...or should we? A lot of people used SQTM when ranking algs and I'm inclined to believe that this is a good idea. 



mark49152 said:


> Besides, move counts of optimal solutions aren't exactly a great "speedsolving quantifier", regardless of metric.



True, they're not great - but they're pretty good!


----------



## MatejMuzatko (Dec 14, 2013)

CFOP is not efficient a lot, but there's easier recognition => more things you can focus on => better fluidity I guess...


----------



## Dapianokid (Dec 14, 2013)

The guy above me sums up the purpose of CFOP and the entire reason behind it's existence.
Forgive me if I think that the more advanced BLD methods and techniques are beyond me. only a gifted special few use them, not because of the fact that they might not practice as much, but simply becuase it takes a gifted mind to memorize and solve a cube in less than 35 seconds.
Similar concepts apply to speedsolving in general. Only a gifted few can use better methods well, with the same proficiency and mastery as those of us mortals who use CFOP.
*Goes and tries to get sub-10 at Petrus*


----------



## mark49152 (Dec 17, 2013)

Kirjava said:


> A lot of people used SQTM when ranking algs and I'm inclined to believe that this is a good idea.


Possibly. When I did my study comparing 1-look and 2-look OLL, I tried a few different approaches and found the best correlation between metric and execution time by using STM but counting half-turns as 1.5 and rotations as 2 - but that's just me and it might not work for others' turning styles. Also, I was measuring widely-used OLL algs, and the correlation still varied according to the flow of the algs; when applied to Cube Explorer optimum solutions with less consistent finger-tricks and without down-selection to choose the better solutions, I would speculate that the correlation would be much weaker.

Secondly, execution time for an intuitive step like pairs or blocks depends as much (often more) on recognising patterns and figuring out moves than it does on actual move execution speed, and so move efficiency is only one indicator of the method's potential.

Thus I didn't make any claims about execution times, and focused only on move efficiency for the analysis in the OP (albeit with not the best choice of metric).



MatejMuzatko said:


> CFOP is not efficient a lot, but there's easier recognition => more things you can focus on => better fluidity I guess...


Indeed. What prompted me to start this thread was the observation that actually the potential move efficiency of CFOP was more limited, and much weaker compared to blockbuilding, than I had realized before. So today we have two common approaches:-

*CFOP pairs: *More formulaic and simpler to master due to focus on fewer pieces at a time. Thus easier to achieve fast, smooth TPS and lookahead. However, maximum efficiency is almost half that of blockbuilding when focusing on one slot at a time. And, typical execution efficiency is already close to that maximum, so it doesn't allow much room for improvement. The usual approach to focusing on more than one slot (multislotting) does not improve maximum efficiency by much. (TL;DR version: CFOP has already reached its efficiency limit so it's all down to TPS.)
*Blockbuilding: *More free-form and difficult to master. However, optimum efficiency is much better than CFOP. Typical execution efficiency is poor compared to optimum efficiency, but that presents much better potential for improvement, even if that improvement is difficult.

What I'm interested in is whether there could be a hybrid between these approaches that retains some of the simple formulaic approach of CFOP but improving the efficiency towards that of blockbuilding. I'm not convinced multislotting is the way forward (sorry about the misleading thread title). Perhaps taking blockbuilding and creating some simple patterns to make it more formulaic is the way to go. (I'd be surprised if that formalisation hadn't been attempted already, given that most people probably block build that way anyway.)

Even if it's impossible or unrealistic, it seems like a relatively under-explored aspect of speedcubing, by contrast with the plethora of LL/LS submethods.


----------



## Escher (Dec 18, 2013)

mark49152 said:


> What I'm interested in is whether there could be a hybrid between these approaches that retains some of the simple formulaic approach of CFOP but improving the efficiency towards that of blockbuilding. I'm not convinced multislotting is the way forward (sorry about the misleading thread title).



Well, the funny thing for me is that I think that one of the weaknesses of blockbuilding is that it's hard to crowdsource approaches and is very individualistic in terms of reaching the end-point, even if two solvers eventually might converge on the same solution. Although multi-slotting in CFOP can feel a lot like that (and is currently in an identical state), because the building-blocks for it are so bite-size and easy to understand, it should be possible to make a set of principles that people can follow in order to improve their efficiency considerably. If you're willing to theorise some perspectives from the blockbuilding perspective I'm happy to work from the other direction! Idealistically speaking, a 'human optimal' approach towards multi-slotting would produce something where the 'CF' framework of 'CFOP' is hardly recognisable, yet can be broken down so that it's understandable from that perspective. Given I rarely solve for speed these days and focus more on intelligent f2l solutions means it's probably laziness on my part that I haven't managed to get a great deal closer to that, but I'm sure Kir would be willing to vouch for the few times I've done example solves that have been 'retarded', haha.

That said, I think that Roux is by far the best method proposed for solving 3x3x3. The way each step is broken down is amazing, when considered in terms of moving throughout the solve from the intuitive and efficient nature of blockbuilding towards the advantages of easily categorised sets towards the end. I love it.


----------



## elrog (Dec 18, 2013)

Escher said:


> That said, I think that Roux is by far the best method proposed for solving 3x3x3. The way each step is broken down is amazing, when considered in terms of moving throughout the solve from the intuitive and efficient nature of blockbuilding towards the advantages of easily categorised sets towards the end. I love it.


I wouldn't say by far. I think it is the best as of now (though CFOP is very close behind and its ridiculous to say otherwise because of the records set with it), but there are still other methods to be explored. I think Roux, and a Waterman/Roux (more Roux than waterman) method I've come up with could be just as good. But I'm currecntly exploring using small alg sets to make recog and recall extremely fsat and easy in my method called Navi.

I personally think that the best way to start of blockbiulding is to do a 1x2x3 block and expand to a 2x2x3. It can be just as efficient, yet you plan more during inspection. This doesn't get you past the point of the 2x2x3 though. After that, I'm not sure what a really efficient way to blockbuild would be, though I've been playing with a method that solves a 1x2x3 on the D face, then solves the E edges, and proceeds to solve the last 3 pieces of F2L with the top layer using alg sets that have not been made.


----------



## Escher (Dec 18, 2013)

elrog said:


> I wouldn't say by far. I think it is the best as of now (though CFOP is very close behind and its ridiculous to say otherwise because of the records set with it), but there are still other methods to be explored. I think Roux, and a Waterman/Roux (more Roux than waterman) method I've come up with could be just as good. But I'm currecntly exploring using small alg sets to make recog and recall extremely fsat and easy in my method called Navi.



Whut? If you're gonna say stuff like this at least describe your idea.




elrog said:


> I personally think that the best way to start of blockbiulding is to do a 1x2x3 block and expand to a 2x2x3. It can be just as efficient, yet you plan more during inspection. This doesn't get you past the point of the 2x2x3 though.



I actually don't agree with this. Expansion from a 1x2x3 can be extremely inefficient (consider what you have to destroy to place your edges) in comparison to how many other pieces on the cube you can usefully solve in the same number of moves.


----------



## elrog (Dec 20, 2013)

Escher said:


> Whut? If you're gonna say stuff like this at least describe your idea.
> 
> 
> 
> ...



I have described my idea pretty in depth in the New Method/Concept/Idea Thread. It is the last post on page 11 assuming you have 10 posts per page.

Expanding from a 1x2x3 to a 2x2x3 does not take many moves. If you make the 1x2x3 block on the left like in Roux, you can easily place the DF and DB edges using R, U, Rw, and M moves. It is very quick to do.


----------



## mark49152 (Jul 16, 2014)

mark49152 said:


> In theory, if multi-slotting could be useful in ~50% of cases, when setting up the last three pairs, and if in each case it eliminates 3 moves from the setup of the next pair without adding additional moves to the insertion, that’s an average saving of 4.5 moves/solve reducing typical F2L pairs to 24.5 moves or ~3.1 moves/piece. So multi-slotting is not a holy grail, just an interesting idea that given the inefficiency of F2L, might be worthy of further development.


I started playing with multi-slotting again with the intention of seeking out the most useful cases and validating the assumptions above. Although I haven't changed my view that the overall potential of multi-slotting is well short of block building, it turns out that some cases can save a significant number of moves and it could be worth learning those selectively.

I broke the cases down similarly to the Absolute F2L site, as pairs of simple inserts with different AUFs in between. For each insert-AUF-insert sequence, I looked at what the move count would be if you instead did the simplest (naive) insert on the first pair with no regard to the second pair. Then I ranked the cases by the difference between these move counts (using predicted ETM). Obviously the worst scenarios are where a simple insert of the first pair sets the second pair up into a nasty 11-move case such as #23/24 (wiki numbering).

Just looking at connected first pairs, so far, I found 11 cases that potentially save 7 or more moves, with an average saving of 8.4 moves. This excludes the "obvious" cases where when the second pair is already made and you just try to preserve it when inserting the first. When I get time, I will also look at the split first pair cases.

So how useful is it likely to be? The probability of getting any one specific configuration of the second pair depends on how many slots are unsolved. I make it 1/98, 1/108 and 1/150 when solving the 1st, 2nd and 3rd slots respectively. Assuming roughly 50% of F2L pairs are connected before insertion and the cuber learns all these 11 cases, there is a better than 1/8 chance per solve of hitting one of these cases and being able to benefit from an ~8 move saving. That seems pretty worthwhile to me.

If anyone's interested in this, let me know and I'll post them in a PDF.


----------



## CriticalCubing (Jul 16, 2014)

mark49152 said:


> I started playing with multi-slotting again with the intention of seeking out the most useful cases and validating the assumptions above. Although I haven't changed my view that the overall potential of multi-slotting is well short of block building, it turns out that some cases can save a significant number of moves and it could be worth learning those selectively.
> 
> I broke the cases down similarly to the Absolute F2L site, as pairs of simple inserts with different AUFs in between. For each insert-AUF-insert sequence, I looked at what the move count would be if you instead did the simplest (naive) insert on the first pair with no regard to the second pair. Then I ranked the cases by the difference between these move counts (using predicted ETM). Obviously the worst scenarios are where a simple insert of the first pair sets the second pair up into a nasty 11-move case such as #23/24 (wiki numbering).
> 
> ...


A PDF would be nice and the thread seems really interesting. I can say anything about f2l and multi slotting and my look ahead is not only great. Haha but still getting to know these stuff is good enough!


----------



## abunickabhi (Oct 9, 2014)

I think Free Fop is the solution.Roux is hard to implement and moves/ piece is more in standard CFOP.so Free FOP will give more degree of freedom.CFOP is the key for next 5 years.i don't see any breakthroughs coming.CFOP is like English not the most pure and oldest language but has too many resources and tricks


----------



## mark49152 (Nov 28, 2014)

After a break of a few weeks I'm back looking at multi-slotting, and following my earlier study of different inserts, decided to tackle the following more general question: *Given a pair already set up to insert, what good shortcuts exist to both insert that pair and set up the next pair at the same time?*

Ignoring slots other than the target slot, and for a single configuration of the first pair, there are 96 possible configurations for the second pair pieces.

I wrote some code to generate all 96 cases (when first pair set up for R U' R'), feed them into ksolve+ and filter and format the results. In the spoiler below you will find all cases/solutions that take less than 6 moves, or optimal+1 moves, whichever is shortest. For each case, I generated four sets of solutions, forming both connected (R U' R') and split (R U R') insertion patterns, and both preserving and flipping the orientation of the second edge.

Some of these solutions are obvious, some are not really finger-friendly, but some are really neat tricks. Some of my favorites include A24, A28, A45 and A54. There were also some nice ones of length 7+ but also lots of junk so I've filtered out all >6. Cases with no <7 solutions also aren't shown.

I will also define groups B, C, etc. with different configurations of the first pair and generate solutions for those too.

_EDIT: Updated with solutions to set up split pairs._

Enjoy 



Spoiler









*Case A02*
*Leave the pair split, preserving the edge*
(U) B' R U' R' U B (U2 B' U' B) [6]
L' U R U' L R' (U' B' U' B) [6]





*Case A03*
*Leave the pair split, flipping the edge*
(U2) R U' B U' B' R' (U2 B' U' B) [6]





*Case A05*
*Connect the pair, preserving the edge*
R' F R F' (U L U2 L') [4]





*Case A06*
*Connect the pair, flipping the edge*
(U2) R U' B U' B' R' (L U2 L') [6]





*Case A07*
*Connect the pair, preserving the edge*
(U) B' R U' R' U B (L U2 L') [6]
L' U R U' L R' (U L U2 L') [6]
*Leave the pair split, flipping the edge*
R' F R F' (U' B' U' B) [4]





*Case A09*
*Leave the pair split, preserving the edge*
(U) R B U' B' R' (L U L') [5]
(U) F' U F R U' R' (U' L U L') [6]
(U) F' U' L' U' L F (U L U L') [6]
(U') F' U' F R U2 R' (L U L') [6]





*Case A10*
*Connect the pair, preserving the edge*
(U) R2 B' R' B U' R' (B' U2 B) [6]
(U2) F R' F' R2 U2 R' (B' U2 B) [6]
*Leave the pair split, flipping the edge*
L R' F R F' L' (U L U L') [6]





*Case A11*
*Leave the pair split, preserving the edge*
(U) F' L' U2 L U F (U' L U L') [6]





*Case A12*
*Connect the pair, preserving the edge*
(U) R U' R' (U' B' U2 B) [3]
(U2) R U2 R' (U B' U2 B) [3]
*Leave the pair split, flipping the edge*
(U) R2 B' R' B U' R' (U2 L U L') [6]
(U) F' U2 F R U' R' (U2 L U L') [6]
(U) F' L' U' L F (L U L') [5]
(U2) F R' F' R2 U2 R' (U2 L U L') [6]





*Case A13*
*Leave the pair split, preserving the edge*
(U) R U' R' (U L U L') [3]





*Case A14*
*Connect the pair, preserving the edge*
(U) F' U2 F R U' R' (B' U2 B) [6]
(U) F' L' U' L F (U2 B' U2 B) [5]
B' R' F R B F' (U2 B' U2 B) [6]
*Leave the pair split, flipping the edge*
(U2) F2 L F L' F (U' L U L') [5]
(U) R' F R F2 U F (U' L U L') [6]





*Case A15*
*Connect the pair, flipping the edge*
(U) F' L' U2 L U F (U B' U2 B) [6]
*Leave the pair split, preserving the edge*
(U2) R U2 R' (U' L U L') [3]





*Case A16*
*Leave the pair split, flipping the edge*
B' R' F R B F' (L U L') [6]





*Case A17*
*Connect the pair, preserving the edge*
(U) R U' R' (U' L U2 L') [3]
*Connect the pair, flipping the edge*
R' F R F' (U B' U2 B) [4]
*Leave the pair split, flipping the edge*
B' R' F R B F' (B' U' B) [6]





*Case A18*
*Connect the pair, preserving the edge*
(U2) R U' B U' B' R' (B' U2 B) [6]
*Leave the pair split, preserving the edge*
(U2) R U2 R' (U' B' U' B) [3]





*Case A19*
*Connect the pair, preserving the edge*
B' R' F R B F' (U2 L U2 L') [6]
*Leave the pair split, preserving the edge*
R' F R F' (U' L U L') [4]





*Case A21*
*Connect the pair, preserving the edge*
(U2) R U2 R' (U L U2 L') [3]
*Leave the pair split, flipping the edge*
(U) R2 B' R' B U' R' (U2 B' U' B) [6]
(U2) F R' F' R2 U2 R' (U2 B' U' B) [6]
(U) F' L' U2 L U F (U' B' U' B) [6]





*Case A22*
*Connect the pair, flipping the edge*
(U) R B U' B' R' (U2 L U2 L') [5]
(U) F' U F R U' R' (U L U2 L') [6]
(U) F' U' L' U' L F (U' L U2 L') [6]
(U') F' U' F R U2 R' (U2 L U2 L') [6]
*Connect the pair, preserving the edge*
(U) B' R U' R' U B (B' U2 B) [6]
L' U R U' L R' (U B' U2 B) [6]
*Leave the pair split, preserving the edge*
L R' F R F' L' (U B' U' B) [6]





*Case A23*
*Connect the pair, preserving the edge*
(U) R2 B' R' B U' R' (L U2 L') [6]
(U2) F R' F' R2 U2 R' (L U2 L') [6]
*Leave the pair split, preserving the edge*
(U2) R U' B U' B' R' (U2 L U L') [6]
*Leave the pair split, flipping the edge*
(U) R B U' B' R' (B' U' B) [5]
(U) F' U2 F R U' R' (U2 B' U' B) [6]
(U) F' L' U' L F (B' U' B) [5]
(U2) F2 L F L' F (U' B' U' B) [5]
(U) R' F R F2 U F (U' B' U' B) [6]
(U) F' U F R U' R' (U' B' U' B) [6]
(U) F' U' L' U' L F (U B' U' B) [6]
(U') F' U' F R U2 R' (B' U' B) [6]





*Case A24*
*Connect the pair, flipping the edge*
L R' F R F' L' (U' L U2 L') [6]
*Leave the pair split, preserving the edge*
(U) R U' R' (U B' U' B) [3]





*Case A25*
*Leave the pair split, preserving the edge*
(U) R2 B' R' B U' R' (L U L') [6]
(U2) R U' B U' B' R' (L U L') [6]
(U2) F R' F' R2 U2 R' (L U L') [6]





*Case A26*
*Leave the pair split, flipping the edge*
B' R' F R B F' (U L U L') [6]
*Leave the pair split, preserving the edge*
(U) F' L' U' L F (U2 B' U' B) [5]
(U2) F2 L F L' F (U B' U' B) [5]
(U) R' F R F2 U F (U B' U' B) [6]
(U) F' U2 F R U' R' (B' U' B) [6]





*Case A27*
*Connect the pair, flipping the edge*
(U) R2 B' R' B U' R' (U2 B' U2 B) [6]
(U2) F R' F' R2 U2 R' (U2 B' U2 B) [6]
*Leave the pair split, preserving the edge*
(U2) R U2 R' (U L U L') [3]





*Case A28*
*Connect the pair, preserving the edge*
B' R' F R B F' (U' B' U2 B) [6]
(U) F' L' U2 L U F (U' B' U2 B) [6]





*Case A29*
*Leave the pair split, flipping the edge*
(U) R B U' B' R' (U2 B' U' B) [5]
(U') F' U' F R U2 R' (U2 B' U' B) [6]





*Case A32*
*Connect the pair, flipping the edge*
(U) R B U' B' R' (L U2 L') [5]
(U) F' L' U' L F (L U2 L') [5]
(U2) F2 L F L' F (U' L U2 L') [5]
(U') F' U' F R U2 R' (L U2 L') [6]
(U) R' F R F2 U F (U' L U2 L') [6]
(U) F' U2 F R U' R' (U2 L U2 L') [6]
*Connect the pair, preserving the edge*
(U2) R U2 R' (U' B' U2 B) [3]
*Leave the pair split, flipping the edge*
(U) F' L' U2 L U F (U L U L') [6]





*Case A33*
*Connect the pair, preserving the edge*
(U2) R U2 R' (U' L U2 L') [3]
*Connect the pair, flipping the edge*
L R' F R F' L' (U B' U2 B) [6]
*Leave the pair split, preserving the edge*
L' U R U' L R' (L U L') [6]
(U) B' R U' R' U B (U' L U L') [6]





*Case A34*
*Leave the pair split, preserving the edge*
(U) F' L' U2 L U F (U B' U' B) [6]





*Case A35*
*Leave the pair split, preserving the edge*
(U) R U' R' (U' L U L') [3]





*Case A36*
*Connect the pair, flipping the edge*
(U2) R U' B U' B' R' (U2 L U2 L') [6]





*Case A37*
*Leave the pair split, flipping the edge*
(U2) R U' B U' B' R' (B' U' B) [6]





*Case A38*
*Connect the pair, flipping the edge*
(U) R2 B' R' B U' R' (U2 L U2 L') [6]
(U) F' L' U2 L U F (U' L U2 L') [6]
(U2) F R' F' R2 U2 R' (U2 L U2 L') [6]
*Connect the pair, preserving the edge*
(U) R U' R' (U B' U2 B) [3]
R' F R F' (U2 B' U2 B) [4]
*Leave the pair split, flipping the edge*
(U) F' U F R U' R' (U2 L U L') [6]
(U) F' U' L' U' L F (L U L') [6]
*Leave the pair split, preserving the edge*
(U2) R U2 R' (U B' U' B) [3]





*Case A39*
*Connect the pair, flipping the edge*
(U) F' U F R U' R' (B' U2 B) [6]
(U) F' U' L' U' L F (U2 B' U2 B) [6]





*Case A40*
*Connect the pair, flipping the edge*
B' R' F R B F' (U' L U2 L') [6]
*Connect the pair, preserving the edge*
L' U R U' L R' (U2 B' U2 B) [6]
(U) B' R U' R' U B (U B' U2 B) [6]
*Leave the pair split, flipping the edge*
R' F R F' (L U L') [4]
*Leave the pair split, preserving the edge*
(U) R2 B' R' B U' R' (B' U' B) [6]
(U2) F R' F' R2 U2 R' (B' U' B) [6]





*Case A41*
*Leave the pair split, flipping the edge*
R' F R F' (B' U' B) [4]





*Case A42*
*Connect the pair, preserving the edge*
(U) R B U' B' R' (B' U2 B) [5]
(U') F' U' F R U2 R' (B' U2 B) [6]
*Leave the pair split, preserving the edge*
(U) R U' R' (U' B' U' B) [3]





*Case A43*
*Connect the pair, preserving the edge*
R' F R F' (U2 L U2 L') [4]
*Connect the pair, flipping the edge*
(U) F' L' U' L F (B' U2 B) [5]
(U) F' U2 F R U' R' (U2 B' U2 B) [6]
*Leave the pair split, preserving the edge*
(U) R B U' B' R' (U2 L U L') [5]
(U2) F2 L F L' F (U L U L') [5]
(U') F' U' F R U2 R' (U2 L U L') [6]
(U) R' F R F2 U F (U L U L') [6]





*Case A45*
*Connect the pair, preserving the edge*
L R' F R F' L' (U L U2 L') [6]
*Connect the pair, flipping the edge*
(U2) F2 L F L' F (U' B' U2 B) [5]
(U) R' F R F2 U F (U' B' U2 B) [6]
*Leave the pair split, preserving the edge*
(U) F' L' U' L F (U2 L U L') [5]
(U) F' U2 F R U' R' (L U L') [6]





*Case A46*
*Leave the pair split, preserving the edge*
L' U R U' L R' (B' U' B) [6]
(U) B' R U' R' U B (U' B' U' B) [6]





*Case A47*
*Connect the pair, preserving the edge*
(U) R U' R' (U L U2 L') [3]
*Leave the pair split, flipping the edge*
L R' F R F' L' (U' B' U' B) [6]





*Case A49*
*Connect the pair, preserving the edge*
(U) R B U' B' R' (U' L U2 L') [5]
L' U R U' L R' (U' L U2 L') [6]
(U) B' R U' R' U B (U2 L U2 L') [6]
(U') F' U' F R U2 R' (U' L U2 L') [6]
*Leave the pair split, preserving the edge*
(U) R U' R' (L U L') [3]





*Case A50*
*Leave the pair split, preserving the edge*
(U2) R U' B U' B' R' (U' B' U' B) [6]





*Case A51*
*Connect the pair, preserving the edge*
(U2) R U2 R' (L U2 L') [3]





*Case A52*
*Connect the pair, flipping the edge*
(U) F' L' U' L F (U' L U2 L') [5]
(U) F' U2 F R U' R' (U L U2 L') [6]
*Leave the pair split, preserving the edge*
(U) R B U' B' R' (U B' U' B) [5]
(U) F' L' U2 L U F (U2 B' U' B) [6]
(U') F' U' F R U2 R' (U B' U' B) [6]





*Case A53*
*Leave the pair split, flipping the edge*
(U) F' U F R U' R' (U B' U' B) [6]
(U) F' U' L' U' L F (U' B' U' B) [6]





*Case A54*
*Connect the pair, preserving the edge*
L R' F R F' L' (U2 B' U2 B) [6]
*Leave the pair split, flipping the edge*
(U) R2 B' R' B U' R' (U' L U L') [6]
(U2) F R' F' R2 U2 R' (U' L U L') [6]
*Leave the pair split, preserving the edge*
R' F R F' (U B' U' B) [4]
(U) F' L' U' L F (U B' U' B) [5]





*Case A55*
*Connect the pair, preserving the edge*
(U2) R U' B U' B' R' (U L U2 L') [6]





*Case A56*
*Connect the pair, flipping the edge*
R' F R F' (U' L U2 L') [4]
*Connect the pair, preserving the edge*
(U) R U' R' (U2 B' U2 B) [3]
*Leave the pair split, flipping the edge*
L R' F R F' L' (L U L') [6]
*Leave the pair split, preserving the edge*
(U2) R U2 R' (U2 B' U' B) [3]





*Case A57*
*Connect the pair, flipping the edge*
B' R' F R B F' (U B' U2 B) [6]
*Leave the pair split, preserving the edge*
(U2) F2 L F L' F (U2 L U L') [5]
(U) R' F R F2 U F (U2 L U L') [6]
*Leave the pair split, flipping the edge*
L R' F R F' L' (B' U' B) [6]





*Case A58*
*Leave the pair split, preserving the edge*
(U) R2 B' R' B U' R' (U' B' U' B) [6]
(U2) F R' F' R2 U2 R' (U' B' U' B) [6]





*Case A59*
*Connect the pair, preserving the edge*
(U) R U' R' (U2 L U2 L') [3]
*Leave the pair split, preserving the edge*
B' R' F R B F' (U' L U L') [6]





*Case A60*
*Connect the pair, flipping the edge*
(U) R2 B' R' B U' R' (U L U2 L') [6]
(U2) F R' F' R2 U2 R' (U L U2 L') [6]





*Case A62*
*Leave the pair split, preserving the edge*
(U) R U' R' (B' U' B) [3]





*Case A63*
*Connect the pair, flipping the edge*
(U2) F2 L F L' F (B' U2 B) [5]
(U) R' F R F2 U F (B' U2 B) [6]





*Case A65*
*Leave the pair split, preserving the edge*
(U) F' L' U2 L U F (U2 L U L') [6]





*Case A66*
*Connect the pair, preserving the edge*
(U2) R U2 R' (B' U2 B) [3]
*Leave the pair split, flipping the edge*
R' F R F' (U L U L') [4]





*Case A67*
*Connect the pair, preserving the edge*
(U2) F2 L F L' F (L U2 L') [5]
(U) R' F R F2 U F (L U2 L') [6]
*Leave the pair split, preserving the edge*
(U) F' U F R U' R' (U L U L') [6]
(U) F' U' L' U' L F (U' L U L') [6]





*Case A68*
*Connect the pair, preserving the edge*
R' F R F' (U' B' U2 B) [4]
*Leave the pair split, flipping the edge*
(U2) R U' B U' B' R' (U' L U L') [6]





*Case A69*
*Connect the pair, preserving the edge*
B' R' F R B F' (U L U2 L') [6]
*Connect the pair, flipping the edge*
(U) R B U' B' R' (U' B' U2 B) [5]
(U) F' L' U2 L U F (B' U2 B) [6]
(U2) R U' B U' B' R' (U B' U2 B) [6]
(U') F' U' F R U2 R' (U' B' U2 B) [6]
*Leave the pair split, preserving the edge*
(U2) R U2 R' (U2 L U L') [3]
*Leave the pair split, flipping the edge*
(U2) F2 L F L' F (U2 B' U' B) [5]
(U) R' F R F2 U F (U2 B' U' B) [6]





*Case A71*
*Leave the pair split, flipping the edge*
B' R' F R B F' (U' B' U' B) [6]





*Case A72*
*Leave the pair split, flipping the edge*
(U) R B U' B' R' (U L U L') [5]
(U) F' L' U' L F (U L U L') [5]
(U) F' U2 F R U' R' (U' L U L') [6]
(U') F' U' F R U2 R' (U L U L') [6]





*Case A73*
*Leave the pair split, preserving the edge*
(U) F' L' U' L F (U' L U L') [5]
(U) F' U2 F R U' R' (U L U L') [6]





*Case A74*
*Connect the pair, preserving the edge*
(U) R U' R' (B' U2 B) [3]





*Case A75*
*Connect the pair, preserving the edge*
(U) F' L' U2 L U F (U2 L U2 L') [6]





*Case A76*
*Leave the pair split, preserving the edge*
(U2) R U2 R' (B' U' B) [3]





*Case A77*
*Leave the pair split, preserving the edge*
R' F R F' (U2 L U L') [4]





*Case A78*
*Leave the pair split, flipping the edge*
(U) R B U' B' R' (U' L U L') [5]
(U') F' U' F R U2 R' (U' L U L') [6]





*Case A79*
*Connect the pair, preserving the edge*
(U2) R U2 R' (U2 L U2 L') [3]
*Connect the pair, flipping the edge*
R' F R F' (B' U2 B) [4]
(U) R B U' B' R' (U B' U2 B) [5]
(U) F' L' U' L F (U B' U2 B) [5]
*Leave the pair split, preserving the edge*
(U) R U' R' (U2 L U L') [3]
*Leave the pair split, flipping the edge*
(U) F' L' U2 L U F (B' U' B) [6]





*Case A82*
*Connect the pair, flipping the edge*
R' F R F' (L U2 L') [4]
*Connect the pair, preserving the edge*
(U2) F2 L F L' F (U2 B' U2 B) [5]
(U) R' F R F2 U F (U2 B' U2 B) [6]
*Leave the pair split, preserving the edge*
(U) R B U' B' R' (U' B' U' B) [5]
(U') F' U' F R U2 R' (U' B' U' B) [6]





*Case A83*
*Connect the pair, preserving the edge*
(U) R B U' B' R' (U L U2 L') [5]
(U') F' U' F R U2 R' (U L U2 L') [6]
*Connect the pair, flipping the edge*
(U2) R U' B U' B' R' (U' B' U2 B) [6]
*Leave the pair split, flipping the edge*
(U) F' L' U' L F (U' B' U' B) [5]
(U) F' U2 F R U' R' (U B' U' B) [6]





*Case A84*
*Leave the pair split, preserving the edge*
(U) R U' R' (U2 B' U' B) [3]
R' F R F' (U2 B' U' B) [4]





*Case A85*
*Connect the pair, preserving the edge*
(U) R U' R' (L U2 L') [3]
*Connect the pair, flipping the edge*
(U) F' U' L' U' L F (B' U2 B) [6]
(U) R2 B' R' B U' R' (U' B' U2 B) [6]
(U) F' U F R U' R' (U2 B' U2 B) [6]
(U2) F R' F' R2 U2 R' (U' B' U2 B) [6]





*Case A86*
*Leave the pair split, flipping the edge*
(U2) R U' B U' B' R' (U L U L') [6]





*Case A87*
*Leave the pair split, preserving the edge*
(U) R2 B' R' B U' R' (U L U L') [6]
(U2) F R' F' R2 U2 R' (U L U L') [6]





*Case A88*
*Leave the pair split, flipping the edge*
(U) F' U' L' U' L F (U2 L U L') [6]
(U2) F2 L F L' F (L U L') [5]
(U) R' F R F2 U F (L U L') [6]
(U) F' U F R U' R' (L U L') [6]





*Case A89*
*Connect the pair, preserving the edge*
(U) F' U' L' U' L F (L U2 L') [6]
(U) R2 B' R' B U' R' (U' L U2 L') [6]
(U) F' U F R U' R' (U2 L U2 L') [6]
(U2) R U' B U' B' R' (U' L U2 L') [6]
(U2) F R' F' R2 U2 R' (U' L U2 L') [6]
*Leave the pair split, preserving the edge*
(U2) R U2 R' (L U L') [3]





*Case A90*
*Connect the pair, preserving the edge*
(U) F' L' U2 L U F (U2 B' U2 B) [6]





*Case A91*
*Leave the pair split, flipping the edge*
(U) R2 B' R' B U' R' (U B' U' B) [6]
(U2) F R' F' R2 U2 R' (U B' U' B) [6]





*Case A92*
*Leave the pair split, preserving the edge*
(U) F' U' L' U' L F (U2 B' U' B) [6]
(U2) F2 L F L' F (B' U' B) [5]
(U) R' F R F2 U F (B' U' B) [6]
(U) F' U F R U' R' (B' U' B) [6]





*Case A94*
*Connect the pair, flipping the edge*
(U2) F2 L F L' F (U2 L U2 L') [5]
(U) R' F R F2 U F (U2 L U2 L') [6]
*Connect the pair, preserving the edge*
(U2) R U2 R' (U2 B' U2 B) [3]
*Leave the pair split, flipping the edge*
(U) F' L' U2 L U F (L U L') [6]





*Case A96*
*Leave the pair split, preserving the edge*
(U2) R U' B U' B' R' (U B' U' B) [6]


----------



## Stefan (Nov 28, 2014)

I just had a look at the first case (Case A05). Why is the solution R' F R F' (U L U2 L') and not R' F R F' (L U' L')?


----------



## mark49152 (Nov 28, 2014)

Stefan said:


> I just had a look at the first case (Case A05). Why is the solution R' F R F' (U L U2 L') and not R' F R F' (L U' L')?


Hi Stefan - the objective is to set the second pair up, not solve it directly. The second could be any of the other three pairs, not necessarily back left. I only chose the orange/green pair for clearest distinction from the first pair, and I only provided the insertion part (in parentheses) to help set up the cases.

The reason the insertion part isn't optimized is due to the way I set the solved state up in ksolve+. I solved the pairs to UFR/UF or UFR/UR, then separately appended insertions from there.


----------



## Robert-Y (Nov 28, 2014)

Thanks for these, looking forward to the RUR' set.


----------



## mark49152 (Nov 28, 2014)

Robert-Y said:


> Thanks for these, looking forward to the RUR' set.


Added setups to RUR'-type second pair, to post above . Next up will be the B cases, with RUR' first pair.


----------

