PapaSmurf
Member
Preface
Firstly, it's quite pretentious to include a preface on a forum post, I know. Secondly, all these thoughts have bubbled away for a long time, but this video by Dylan Miller analysing Yiheng's 4.25 insane average has brought it all into focus for me. So here are a lot of thoughts which I hope are helpful/interesting.Introduction
If you're somehow unaware, there has been a lot of thinking about speedsolving methods over the years (see: cubinghistory.com), which has tended towards 4 main method types: layer by layer (LBL), blocks, edge orientation (EO), corners first (CF). In reality, any good method is really just a combination of these concepts. Yes, there are also edges first and corner orientation, but these ideas have mostly been insignificant in method development (except maybe for ECE, which is still arguably CF though). My main aim with this post is to show how the big 4 and variations all really depend on these concepts and are themselves combinations of these. Then I'm going to discuss how ideas from other methods can be imported to influence and optimise each one and how they converge to, it seems, 2 "method centres". Finally, I'll make a comment on how this then applies to method debates, our own speedsolving and other seemingly unrelated things.Section 1 - how concepts combine to create methods
The method that almost everyone learns first is LBL. You solve the cross, then corners (and so solve the first layer), then second layer edges, then the last layer in managable chunks. It's easy to see and make progress, and there's nothing too complicated apart from having to learn a few short algorithms. You cube for a few days, get faster, then cube for a few more days and think "what's next"? The next obvious step is to optimise what you already know. You do this by learning "pure" CFOP. You get better at cross, combine the next two steps into one and learn more algorithms. However, in optimising you lost a little bit of LBL, as you have blurred the lines between the first and the second step. (You could consider a method where you instead combine cross and corners, then do second layer edges. This kind of approach is worse, hence no one using it. The extreme of isolating the first layer means that, to optimise, you should combine the second and third layer, giving L2L). In combining these two steps, you have introduced an element of block building. Instead of solving individual pieces, you are solving 2 at a time in corner-edge blocks we call pairs. So to optimise LBL, we have to relax the rule of working in layers and introduce blocks.We're now going to change tack and look at blocks. Try solving a cube intuitively only using blocks. You can probably do it, but it won't be quick. But that's because a (read: the) point of blocks is to bring you efficiently to a point where you can do some quick, predetermined moves (called algorithms) and solve the cube. If you think about it, that's kinda what CFOP is - you build a 2x3x3 and solve in two algorithms. There are other ways you can do blocks though. The family of Petrus-like methods (such as Petrus, APB, LEOR etc., which, imo, are actually just the same method), bring you to a state of (EO)2x2x3, and you go from there to build the rest of F2L to leave you with a LL. There are also other ways to do blocks in a Fransisco style for example, but all of these tend towards Petrus anyway. For a very long time, CFOP users have implemented more blocks through their use of extended cross (xcross) and other similar ideas. This doesn't mean that top level CFOP solvers use Petrus, but there are certainly ideas that are common to both methods that means they expand beyond the boundaries of strict CFOP or 2x2x3->EOF2L. Another idea that is now quite common in CFOP is to avoid diagonal last 2 pairs, which is equivalent to building a 2x2x3 and a D layer edge. Petrus suffered from certain factors that meant it never was a top top level method (including users, some non optimisations, lack of development) which similar methods normally try to fix, but top level solvers, instead of fixing Petrus, improved their own method by bringing Petrus ideas in, thereby making CFOP slightly less "pure", but faster.
Mr ZZ really wanted a reduction method. You go from <RULFDB> gen to <RUL> after the first step of EOLine, then to <RU> after solving left block in a way that would reduce the rest of the cube. When that didn't look feasible, the method vision was adjusted to EO (and middle layer) first, then the rest of F2L by blocks (kinda like the left and right layers, although it's probably not strictly true), then LL. ZZ is really a combination of EO first, LBL and block building. If you solved LB first, you would essentially have a Petrus solve. You could mix sides. You could really do what you want as long as EO wasn't broken, hence the huge number of variants. However, around 2018, people really started to realise that the ergonomics weren't great, so they imported an idea from CFOP (that had been used before, but never by the vast majority, nor never endorsed by the ZZ community) - cross. ZZ went from a LBL middle outwards method to LBL bottom to top, whilst still retaining its signature of EO. This is another example of a method expanding to improve, rather than sticking to a rigid and formulaic way of dong things.
CF was the first method used to solve the cube, it was the first method used to win a worlds and is dominating the OH scene today. Yes, Roux is a CF method. It has blockbuilding integrated in (in a way that makes it a blurry LBL method - left layer, right layer, middle layer), but for the sake of this, you should think of it as a CF method. There are other CF methods out there (LMCF, Skis, Waterman, PCMS) but whenever you try to optimise any of them, you get back to Roux. It just has the best ending of all of them and also the best way to get to that ending. (You could apply this CF approach to CFOP and end up with CFCE, another way to do LL, but this hasn't taken off as there is about 0 benefit over CFOP and everyone already knows the algs.) Roux is already so good it probably needs someone with Yiheng levels of potential to require further optimisation.
Hopefully you can see that all these methods have a main concept driving them (LBL for CFOP, blocks for Petrus, EO for ZZ and CF for Roux) whether knowingly or not, then extra concepts added on top to provide a proper structure and to optimise. This is really the TL;DR for the next part.
Section 2 - optimising methods
\[ t = timer_{start} + timer_{stop} + \frac{T}{\left< Tps \right>} \]
where t is time, T is turns, <Tps> is average Tps. This equation governs speedcubing at a fundamental level. If your Tps tends to infinity, your time will tend to the amount of time it takes you to start and stop the timer legally. Equally, if your solve uses 0 turns, you will get the same result. The whole point of speedsolving is to minimise the time taken, and therefore the equation. You could get a bit faster by optimising timer starts and stops (the whole sliding debate is really about this part of the equation), but the place where there can be most progress for all of us except maybe the top 2 2x2 solvers is with the fraction.Let's probe that fraction from a CFOP point of view, starting with the OP. Some algs are faster than others, maybe due to higher potential Tps or fewer moves, so you would do them (compare L R U2 R' U' R U2 L' U R' to the normal J perm). Another easy thing to do is to drill the algs so that the time it takes you to do them decreases. You can also force better algs by maybe inserting the last pair with a sledge to change the EO or an alternative but near equal OLL (R' U2 R U R' U R vs R U R' U R U2 R' - they do different things to the EP) to force a different PLL. Both of these are ways to optimise your LL, but the last one is something you do the step before (influencing) and the first one is what you do during the step. Recognition is a factor that doesn't fit neatly into either camp (you can sometimes recognise the OLL during LS but sometimes you will have to recognise it after LS), but whatever you do, reducing the time to recognise will also speed up the alg steps as you are increasing the average Tps. Another way to improve LL is to do 2 steps in 1 with a 1LLL. All PLL skips really are is the case where you know the 1LLL for that OLL case without realising. Similarly, an OLL skip is where you know the OLS for that LS case without realising it. If you learn ZBLL, you know all the 1LLL cases for the EO solved OLLs (OCLL). This reduces the time because it reduces the movecount and often the recognition time as well. So there are multiple ways to optimise the alg steps but they all are ways to decrease that fraction.
The CF bit of CFOP can be improved again in 2 different ways: decrease the movecount or increase the turn speed. Xcrosses are good because they are often more efficient than cross->pair and they also mean that you've planned further, which decreases your pausing and in theory means you can turn faster. However, pure blocks is often bad, as you have to think way too much and therefore you sacrifice Tps. So there are some certain guidelines that someone using CFOP can follow that will reduce their pauses, keep their movecount low(ish) and their Tps high. I'll go through a few of these now.
The first one is to solve BL first (for right handers, BR for left handers), as it reduces the number of L moves that you need to do with your weak hand, hence increasing the raw Tps, and also fills in the biggest blindspot, which makes lookahead easier for a sacrifice of 0 moves and therefore increases <Tps>. You should also plan this in inspection if you want to actually be good, reducing the mental load during the solve and therefore increasing <Tps>.
The second one is to avoid having diagonal pairs. This is because it makes lookahead worse, any rotation will put a pair into BL and it requires grip shifts to solve both pairs in most cases. It isn't necessarily a cardinal sin to have this, as you could have a 3 mover into both slots and you'd obviously choose that over a mid solution into non diagonal slots, but it's definitely something to avoid for the most part. To phrase this in the language of the equation, it will reduce <Tps> on average, but there are special cases that, either because there is no effect on <Tps> or because the movecount reduction is great, you can have diagonal pairs. This one is Petrus-y, as you are essentially solving a 2x2x3 (as I mentioned above), so you are kinda blockbuilding in a specific way.
The third one is to try to orientate edges, or at least be aware of their orientation. This is beneficial as if you know which edges are good or bad, you can plan your solution around that to reduce rotations (which, in time, are equivalent to a move or two) or eliminate them entirely. Also, if all edges are good, you can really max out your burst Tps (a bit like driving on a straight in motorsports - you can really push that accelerator). Moreover, with F2L EO solved, diagonal pairs matters less as you're not going to need to rotate and you can focus on turning quickly (although having adjacent pairs remaining is preferred still). If you know that all your edges are good, you can utilise ZBLL and you have minor lookahead gains during F2L, as you can filter out the U edges because they will all have the U colour on a certain face. This is highly ZZ-like, but the benefits when you need to shave .1 seconds off a 4.25 second average are huge if you can implement them. All of these will have the effect of increasing <Tps>, although sometimes it may come at the cost of 1 or 2 moves. So it becomes worthwhile if you can really take advantage of that possible increased Tps ceiling.
These three rules (guidelines) get more important progressively as you get faster, but also so does learning when to break them. I would suggest that CFOP has not yet reached the point, but is nearing that point for sure, where EOCross (or at least partial EOCross) will become the norm at the highest levels. But I'm also going to predict that there is another point beyond that where that rule will be allowed to be broken as the solutions become more and more optimised, in the same way that people genreally try to avoid diagonal pairs, but sometimes they break that rule for something faster that may look more primitive.
To summarise this section: all ways to (meaningfully) improve really come down to either increasing the average Tps or decreasing the movecount, or playing about with both of them in a way that ends up reducing that fraction (such as choosing a longer alg that you can do faster). In CFOP specifically, at the highest levels ideas from ZZ and Petrus are (potentially unknowingly) creeping their way into solves as they allow for optimisations that a raw CFOP requires if times are going to decrease.
Meanwhile, Roux just carries on doing its own thing...
Section 3 - what does any of this mean?
I started off by pointing you to all the method development that has gone on for the past 50 years. A small amount of that development has had a large impact (namely CFOP) and the more of that development you include, the lower the impact has been. So, in order of impact (to speedsolving), you could have a (non comprehensive) list that looks like this: CFOP, Roux, ZZ, Petrus, ZB, LEOR, 2 gen reduction, columns, COLL+1, NCP ZBLL recog (this is very cool and you should check it out), etc. The first few are things you definitely have heard of, then the further down you go, it's less likely that you have heard of it and that it's used. However, we are at the point where some good ZBLS algs are being used to force ZBLL (so ZB), maybe we'll see certain solutions that look somewhat like LEOR because there's a solved square on the scramble, or maybe even 2gr will be a used technique in the far flung future. There's no way we can know for sure without a time machine, but my point is that there are lots of techniques that have their own little niche and can all be used to optimise these base layers (of CFOP and Roux in the current paradigm) in certain circumstances.With this in mind, surely method debates all are pointless beyond a conversation between LBL and CF type methods? If anything beyond these two just gets taken in, then surely we should really be talking in this way instead of CFOP vs ZZ or another combination. CFOP is tending to ZZ and ZZ to CFOP and to recognise that changes how we should think about the way we solve. There's also a finer point in here about method development. There are now two ways to think - do we create another method centre (you could probably argue that DR is this) and see how much it can be optimised and therefore compete with the LBL and CF methods, or do we try to optimise the LBL/CF methods? That's a question for you to think about. There's also a comfort that if you've had a very good idea that does save a move or two, such as non-matching (see here and here), it will probably be implemented eventually. Taking the case of non-matching, pseudoslotting is just that. You make it so the first layer doesn't match the second layer but with the advantage of saving some moves. I can see this being applied to conjugating L or R eventually, forcing people to learn LL recognition methods that can handle it. But whatever happens, these ideas are now out there for whoever to take advantage of, be it an existing cuber or someone who hasn't been born yet.
So to apply this to your solves. You have the equation and so go and reduce it. Don't think in terms of methods per se. Rather think in terms of the paradigm, the method center, Work through how you solve the cube and optimise each step as much as possible. But when you have reached that point, don't think that's all that you can do. Instead, think about how you can blur the lines of your method to help you reduce the time. Maybe you can implement EO ideas into your CFOP solves. Maybe you could learn how to do non-matching blocks in your Roux solves so that you can take advantage of other blocks during SB. Whatever the case may be, if you are a speedsolver the eventual aim is to get that time as close to 0 as possible so do whatever you can to do that.
Conclusion
Hopefully I've made sense. Hopefully this has some sort of impact. Hopefully there's a little less looking down on different ideas (like EO or blocks or Roux or whatever). If anything, this has been therapeutic so it has already done most of its job. However, if it generates discussion, even better. Thank you for reading it and have a nice day, whoever you are wherever you are!I just wrote a 3000 word essay (3063 precisely) on speedcubing stuff. Wow. I've struggled to write that much for any paper or essay I've ever needed to write. And I did it in 2 days. Truly, congrats for reading it all. I hope it actually means something to you. By the way, that's almost 5 pages of A4 on font size 12. I'm seriously impressed with myself and also a little worried that I could do this relatively easily, but I struggled on things like, oh I dunno, my literal dissertation! Anyway, I'll actually stop now. Thanks! 
Last edited:
--EOcross is only ~8 moves, and since all of the edges are oriented he kind of only needs to track corner orientation (which he has proven that he is more than capable of since the dude plans full F2L...)
