CFOP efficiency and multi-slotting

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.
 
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.
 
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
 
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.
 
Last edited:
  • 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?
 
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.
 
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.

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?
 
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.
 
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.

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.

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!
 
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*
 
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).

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.
 
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.
 
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.
 
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.


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.
 
Back
Top