adventures in cubing

There are 21 PLL algorithms, with an average of 15 moves (QTM) each. Those are enormously intimidating figures for someone new to cubing — especially if that someone is, say, in his mid-thirties, has a demanding job, two kids, and, therefore, limited time and energy. And even more so if, as the four readers who occasionally glance at this blog’s carefully produced and curated content already know about me, that someone is just plain bad at memorizing. That’s why, when I began this curious adventure a little bit more than ten months ago, I did so with appropriate humility. I had no illusions of being a 10-second solver, and nary a thought of even consistently approaching 45 seconds. This would be a fun distraction — something I could do interstitially. A low overhead, low footprint hobby. For it to become anything more, I figured, I’d have to do all this memorizing. Perish the thought.

And now this. A video of my version of a PLL speed attack (explanation below), showing my timed execution of the 17 PLLs I know.

Feliks, I am not. But I was excited to be able to perform and document this nevertheless. How’d the guy bad at memorizing get these down? Well, I found that memorizing is one thing, while DOING is something entirely different. Doing is something I, well, do all the time. I’m a doer by nature; I’m a to-do list’s worst enemy. And as I did, I realized that, like most things in life, the more you do them, the more routine they become. Each algorithm started for me as insanely difficult but became more or less rote within a few days. It proved up Jessica Fridrich’s observation that, “The individual moves will be performed ‘by your hands’ rather than making your brain busy. … It is done for you automatically by your subconsciousness!” Indeed. I even found that the more algorithms I learned, the more quickly I could pick up each new one — as though my subconscious had entered a virtuous cycle.

A real PLL speed attack involves doing all 21 PLLs with no break. (A respectable time is less than 90 seconds, a good time is 60 seconds, and an excellent time is 30-ish.) Being a blog for the mediocre, I approached the attack differently. Mine is a partial (the Gs will have to wait) one, done more as speed-walking than a sprint, as indicated by these times:

If you linearly project the total for these 17 cases onto all 21, I’d be in the respectable 64 second range. But that’s unrealistic for a variety of reasons. First, these times represent my best of three attempts. Second, I would not be able to keep up that flow for over a minute and without confusing the algorithms as I went. There’s a big difference between doing them seriatim with breaks to think about each, and just racing through them seamlessly in a real attack.

Being a data junky, I thought it would be interesting to measure each algorithm in terms of the length per move. With wide length differences between the shortest PLL (12 moves) and longest (19 moves), this would be a way of normalizing them to measure the efficiency of executing each of the algorithms:

Surprisingly, the longer algorithms were also the more inefficient per move. I did not expect that to be the case. I had thought that certain combinations of moves might perform more seamlessly, leading certain long algorithms to be more efficient and certain short algorithms to be less so. As further borne out by this scatter chart, there’s instead a pretty direct and consistent correlation between total and per-move length:

One final point that I want to mention involves the PLL case frequency/distribution in the below summary (based on the data from Badmephisto’s site):

While I may know 82% (17) of the cases, it’s interesting to note that the case probabilities are not evenly distributed. The four Gs together have a 22% (4 in 18) chance of occurring. In other words, there is a 78% chance that during any single solve I’ll get one of the 17 cases I know, and a 22% chance that I’ll get one of the four I do not.

22% ain’t nothin’. I guess I should get cracking on those Gs….