−1. Prepreamble
If it looks like this post suddenly ends or is otherwise less polished than it could be, it's because I self-imposed a deadline of finishing this in a fortnight one fortnight ago, and that deadline has come. I started work on this early last year and kind of sat on it; if I let it simmer for any longer there's a good chance either it becomes irrelevant (by virtue of someone else doing the analysis – I can't possibly be the only one who knows programming and basic statistics) or I lose interest and another year will pass with zero progress on this project. Don't let perfect be the enemy of good!
Part of the recent inspiration to resume work was that I competed in megaminx recently, and that marks my 10th megaminx round since getting the Dayan Megaminx Pro M. Most of these official ao5s are better than my global average, and the ao50 of these 50 official solves beats my home PB ao50 by about a second as well. It's unlikely that this is merely due to a different environment, as this huge discrepancy doesn't show up for most other events. Unofficially, I use (a variant of) Pochmann + FB scrambles, which is roughly twice as effective as Pochmann scrambles at mixing the edges and roughly 1.5× as effective at splitting corner-edge pairs. Details in section 3.
0. Preamble
It will sometimes be necessary to distinguish the two, so within this post I'll try to distinguish the scramble format (how the moves used to scramble the puzzle are chosen) versus the scramble notation (how those moves are printed on the scramble sheet). This post focuses on the former, although notation is of course also important.
1. History
Those who don't study history are doomed to repeat past mistakes. Unfortunately, I'm a poor historian, so maybe this is already doomed to failure. Nevertheless!
2. Statistical defects in Pochmann scrambles
The numerical values are either exact (written as a plain integer or fraction), exact up to rounding error (>12 significant figures), or low-precision (3-ish decimal places). Intermediate calculations were done with exact rational arithmetic where possible.
As has been suspected for many years, albeit with scant evidence, Pochmann scrambles turn out to be noticeably poor at mixing up pieces.
Consider the numbers of edge-centre pairs and corner-edge pairs. (Overlaps are counted, so a solved megaminx has 60 edge-centre pairs and 60 corner-edge pairs.)
A "flipped" edge-centre pair is one where the edge is flipped. An edge piece cannot simultaneously be part of a (proper) edge-centre pair and a flipped edge-centre pair, so the total number of edge-centre pairs and flipped pairs is at most 60.
On uniform random-state scrambles, the distribution of the number of edge-centre pairs has mean 5 and variance approximately 5.241. The number of flipped edge-centre pairs has the same distribution (but is not independent; they're weakly anticorrelated). The number of corner-edge pairs has mean 1 and variance approximately 1.000 (and is in fact very close to Poisson).
As Pochmann scrambles don't involve any scrambler state, it is easy to compute the exact expected numbers of such pairs.
It's worth noting that the convergence rates differ between edge-centre pairs and corner-edge pairs; pushing the bias under 1% takes 170 moves for edge-centre pairs and flipped pairs, but "only" 120 moves for corner-edge pairs.
The bias of excess edge-centre pairs nearly perfectly cancels out the bias of deficient flipped pairs, which may explain why Kit Clement's analysis (which ignored EO) found only a small bias.
The existence of these biases can be verified with actual WCA scrambles. 91 megaminx scrambles were used for Rubik's WCA World Championship 2023. (12 groups for first round, 1 group for final; 7 scrambles per group.) Among these 91 scrambles, there were a total of 561 edge-centre pairs (6.16 average), 337 flipped edge-centre pairs (3.70 average), and 119 corner-edge pairs (1.31 average). Under the null hypothesis of the scrambles being sampled from the uniform distribution, these correspond to p-values of 0.00000068 (at least 561 pairs), 0.000000037 (at most 337 pairs) and 0.0028 (at least 119 pairs) respectively, using a normal distribution approximation for the first two and Poisson distribution approximation for the third.
If we reorient the puzzle to initial scramble orientation after applying a Pochmann scramble, we can also ask: which piece-location combinations show up too frequently/infrequently? These are the biggest deviations from uniformity for the edge pieces:
U-F (white-green) edge solved: 1/60 + 0.0064448185252294699 (~39% too likely)
U-BL (white-yellow) edge solved: 1/60 + 0.0064448185252294699 (~39% too likely)
F-DFR (green-cream) edge solved: 1/60 + 0.0061514259936004502 (~37% too likely)
BL-DB (yellow-lime) edge solved: 1/60 + 0.0061514259936004502 (~37% too likely)
For each of the 60 possible corner-edge pairs, we can reorient the puzzle so that the edge is in a fixed location (say, U-L) and find the corner (say, U-L-BL). These are the biggest deviations from uniformity:
U-L-BL (i.e. formed pair): 1/60 + 0.0054246148471100574 (~32% too likely)
L-BL-U (i.e. twisted corner): 1/60 − 0.00093587418368997878 (~5.6% too unlikely)
BL-U-L (i.e. twisted corner): 1/60 − 0.00093587418368997878 (~5.6% too unlikely)
B-BR-BL (i.e. BL2' away from formed pair): 1/60 + 0.00053037747599415802 (~3.2% too likely)
DBL-B-BL (i.e. BL2 away from formed pair): 1/60 + 0.00053037747599415802 (~3.2% too likely)
One useful statistic we can measure here is the difference between the most likely combination and the least likely combination. Another potentially useful statistic is the earth mover's distance (EMD) from the uniform distribution; this measures how many moves we need on average to uniformise the piece's location distribution.
EMD is more sensitive to deviations from uniformity than just looking at average move count to solve a piece. If the average move count differs from uniform random state's average move count by x moves, then the EMD will be at least |x| moves. (EMD is always nonnegative.)
In the following table, we measure the EMD between an edge piece's location distribution and the uniform distribution in two metrics: QTM and 1.5TM. The EMD is calculated for all 30 edge pieces individually, with the average and maximum values out of these 30 EMD values reported below.
(Observe that EMD in QTM and in 1.5TM coincide for long-enough Pochmann scrambles; this does not happen with other scramble formats. This peculiarity appears to be caused by Pochmann scrambles using only 2/5 turns.)
This doesn't really fit anywhere else, but it's worth mentioning that the chance of getting a "square" (a block consisting of a centre, two adjacent edges, and a corner between them) is supposed to be 1/696 with random-state scrambles, but is nearly thrice as common at around 1/240 with 70-move Pochmann scrambles.
3. Alternative scrambling formats
(None of these names are set in stone. Feel free to come up with better names. In fact, also feel free to come up with your own alternative scrambling formats!)
Must-haves:
Nice-to-haves:
I've spoken with Lucas Garron regarding orientation randomisation (he's for, I'm against). Randomising orientation practically means that one-move misscrambles by doing a rotation or a wide move the wrong way will lead to a mostly-different-looking scramble state, which brings up fairness concerns. Orientation randomisation is, however, a very useful way to ensure that every face gets roughly equally scrambled.
3.0. Random-state scramble
This wasn't a thing at the time I initially wrote the first draft of this post (mid 2024), but it is now late 2025 and at least three people have coded reasonably efficient megaminx solvers. Move counts seem to be around 80-90 moves for all of our solvers.
The ones that use subgroup reduction (Alexander Botz's, Chen Shuang's) generally have the issue that the initial part of the solution involves solving F2L at the bottom, with a lot of bottom-hemisphere moves. I don't think either of these two solvers have been publicly released yet, but if you want to get a feel of what it looks like, see csTimer's kilominx random-state scrambles:
Mine instead mimics my kilominx solver, by using U, L, F, R, BR, BL and flip ("x2" in Twizzle): get the bottom-layer pieces out of the top, flip, solve F2L, flip again, solve the rest. Also not publicly released yet (because it's not finished: it still requires manual fiddling for the solution to actually work), but the source code is available on request. Usage of BL and BR moves is deprioritised by having the back blocks solved earlier, so the majority of the solution is ULFR 4-gen.
This took me 42.20 seconds to apply (correctly, first try), which we can use as a benchmark for scrambling formats: if it takes more than 40-ish seconds, we might as well just use random-state scrambles.
3.1. Opposites
Do a random U move and a random D move (where "D" is the face opposite of U), then rotate a random non-UD axis to UD. Repeat.
This one is more of a proof of concept than something that's human usable. It's very simple and mixes the pieces very well, but is absolute hell to execute. I am not recommending this to replace Pochmann scrambles.
The moves can also be written without rotations.
Here's a square-1-like notation for the first two rows of the above scramble sequence. Here, "A(x,y)" means to turn the A face by x and the opposite face by y.
3.2. FBy
I actually came up with this before "Opposites". Same idea, but the moves are on the F and B faces with a y rotation after every pair of moves. The U (white) and D (grey) faces are never turned in this scramble format. All solvable positions are still reachable eventually (verified with GAP).
This is a bit better than Opposites at breaking up pairs and mixing up the pieces.
I have not found a reasonable way of executing this format accurately and quickly. It did, however, inspire the next one…
3.3. RFLy
This is mostly self-descriptive: do a random R move, do a random FL move, y rotate, repeat.
I do this with wrist turns for the R moves and left thumb pushes for the FL moves. Unfortunately, restricting the FL face to 1/5 turns has a huge negative impact on scramble quality; as a compromise, we bias towards 1/5 turns (2/3 chance of FL or FL'; 1/3 chance of FL2 or FL2').
After some practice, I can execute 70-move scrambles in around 38 seconds.
Potential downside: The heavy left thumb usage during scrambling may lead to RSI.
3.4. Roundabout
Do random 1/5 turns on the BL, BR, R, F, L faces in that order, then a random U move, then random 1/5 turns on those five faces again, then flip the puzzle over.
In practice, the "flip" isn't executed in isolation, but together with the next row's BL and BR moves.
Using both 1/5 and 2/5 turns seems to improve mixing, but at the cost of making the ergonomics much worse.
Looking solely at the number of edge-centre pairs and corner-edge pairs, this scramble format fares much better than Pochmann scrambles, even when normalised for similar scrambling time. However, for shorter scramble lengths, there is an asymmetry in how much the pieces are scrambled – the bottom hemisphere's pieces are effectively scrambled for 11 moves less.
It's still asymptotically better than Pochmann scrambles in the long run, but at reasonable scramble lengths, it's worse.
3.5. Pochmann + F
Pochmann scrambles, but with intercalated F moves. Pochmann scrambles leave the UL corner-edge-corner bar untouched most of the time, but by introducing F moves, we regularly break up this bar. Not clear what a good balance of F moves is, but it turns out to not matter too much because there's something better.
3.6. Pochmann + FB
Instead of U moves at the end of each row, we do random F and BL moves instead. For ergonomics reasons, and also for EO reasons, these are restricted to 1/5 turns.
Assuming a standard colour scheme, the white-purple edge will always be in the UL position. Even if one drops the puzzle mid-scramble, it is always possible to pick up the puzzle in the correct orientation and resume.
This is what I've been using for practice, except always doing F and BL' instead of randomised directions. It's a bit slower to do than Pochmann scrambles, but not by too much: standard Pochmann takes me ~21 seconds, the always-(F BL') variant takes me ~23 seconds, and the randomised F* BL* variant takes me ~28 seconds.
Note that even the always-(F BL') variant is much better than Pochmann, and in fact it seems to have (very slightly) better stats than the randomised F* BL* variant. I'm not sure how generalisable this is.
Here are the tables from above, with Pochmann + FB added. As you can see from the data, this is substantially better than 70-move Pochmann scrambles, and even somewhat better than 100-move Pochmann.
3.7. Pochmann with rejection sampling
Generate the scramble sequences as usual, but reject the resulting scrambles that are too easy (or too hard!) and reroll for a new scramble.
Rejection sampling is a general technique for morphing one distribution into another, with fairly lax preconditions. As long as something you want out of the target distribution isn't outright impossible in the source distribution, it's always possible to use rejection sampling to accomplish this morphing.
Rejection sampling was previously proposed by Roman Strakhov for shortening big cube scrambles; here the issue is instead that 70-move Pochmann scrambles are already too short, with glaring statistical defects, so we look to use rejection sampling to bring them up to snuff. However, rejection sampling has major issues:
1. We can't actually apply the standard form of rejection sampling because most legal states aren't even reachable from 70-move Pochmann scrambles. Instead, we look at certain aspects of the scrambles, such as the quantity of edge-centre pairs and edge-centre flipped pairs. The problem then becomes…
2. The source and target distributions are not known exactly and have to be empirically estimated. Rejection sampling does not seem to be robust against inaccurate knowledge of the source and target distributions; if the average number of rejections is small, this is not a huge problem, but frequent rejections can amplify inaccuracies. This is an issue because…
3. A large number of rejections will be needed if the distributions differ a lot. The average number of raw scrambles to generate per output scramble is given by max((pmf of target distribution) / (pmf of source distribution)). (Division here should be interpreted as pointwise division.) If we bin the states by the number of edge-centre pairs (capped at 12) and flipped pairs (also capped at 12), so there are 13² = 169 bins in total, this quantity works out to around 11.3 raw scrambles per output (with huge error bars).
4. Rejection sampling can only fix exactly what we're filtering for. For instance, if we use rejection sampling to fix the excess edge-centre pairs, the resulting scrambles will still be deficient in edge-centre flipped pairs. If we filter for both edge-centre pairs and flipped pairs, then we still have corner-edge pair bias (they're still around 31-32% too likely). It's possible to repeat this but this seems like a never-ending unwinnable battle: what about 1-move pairs? What about corner-edge twisted/flipped pairs? What about 1 move to those? Etc. etc.
5. This is almost certainly not robust against misscrambling. If R++ is replaced by R−− or vice versa (or D++ with D−−) near the middle, that results in a huge change in the puzzle state, which likely invalidates what the rejection sampling algorithm is actually trying to filter. Quite possibly, misscrambles will have biases that are more like unfiltered scrambles. I have not investigated this.
I'm no statistician, so I don't know how fixable these issues are. However, it seems complicated enough that changing the scramble format is a much more attractive option.
4. Conclusion
In lieu of any better suggestion, I strongly recommend switching to Pochmann + FB (either the original randomised F* BL* variant or the fixed F BL' variant) with 7 rows of 12 moves as an interim measure. If we take 99% as our "scrambledness" benchmark, then 7 rows Pochmann + FB still isn't good enough and we will eventually have to upgrade our scrambling method again. (There's more I want to talk about regarding this, but, you know! Deadlines!)
Viability of random-state scrambling may need to be revisited.
Code used for the computations. It's about as jank as you'd expect research code to be, but better to have crap code that you can use to reproduce the results than none at all. There are a few other scramble formats I experimented with in there that I didn't write about in this post.
If it looks like this post suddenly ends or is otherwise less polished than it could be, it's because I self-imposed a deadline of finishing this in a fortnight one fortnight ago, and that deadline has come. I started work on this early last year and kind of sat on it; if I let it simmer for any longer there's a good chance either it becomes irrelevant (by virtue of someone else doing the analysis – I can't possibly be the only one who knows programming and basic statistics) or I lose interest and another year will pass with zero progress on this project. Don't let perfect be the enemy of good!
Part of the recent inspiration to resume work was that I competed in megaminx recently, and that marks my 10th megaminx round since getting the Dayan Megaminx Pro M. Most of these official ao5s are better than my global average, and the ao50 of these 50 official solves beats my home PB ao50 by about a second as well. It's unlikely that this is merely due to a different environment, as this huge discrepancy doesn't show up for most other events. Unofficially, I use (a variant of) Pochmann + FB scrambles, which is roughly twice as effective as Pochmann scrambles at mixing the edges and roughly 1.5× as effective at splitting corner-edge pairs. Details in section 3.
0. Preamble
It will sometimes be necessary to distinguish the two, so within this post I'll try to distinguish the scramble format (how the moves used to scramble the puzzle are chosen) versus the scramble notation (how those moves are printed on the scramble sheet). This post focuses on the former, although notation is of course also important.
1. History
Those who don't study history are doomed to repeat past mistakes. Unfortunately, I'm a poor historian, so maybe this is already doomed to failure. Nevertheless!
From 2004 to 2007, the WCA used a 12-gen megaminx scramble format. [1] The front hemisphere faces are labelled uppercase A through F, and the hind hemisphere faces are labelled lowercase A through F (opposite faces have the same letter). It looked like this:
It was notorious for being hard to apply correctly and quickly. (In fact, I'm not even sure if I translated it to Twizzle notation correctly.) Nobody liked it!
This scramble format is not symmetrical across all 12 faces (although whatever bias is present is probably negligible). The scramble program (by Jaap) only tracks the previously moved face, and rejects a newly chosen face if it commutes with the previous face and comes later in the ABCDEFabcdef ordering. This is different from e.g. qqTimer's implementation, which tracks all previous moves that commute with each other, and rejects a newly chosen face iff it cancels an earlier move.
In 2007, Stefan Pochmann introduced an early prototype of the megaminx scramble format that we now use. [2][3] Key differences from modern Pochmann scrambles are that the moves can be 1/5 turns or 2/5 turns; the rotation at the end of each row is a 180° rotation around the F-DFR edge (except the last row doesn't need a rotation); and the scramble sequence consists of 100 moves (10 rows of 10 moves).
In 2008, the WCA adopted Stefan's scramble format as we know it today: 7 rows of 10 moves, all 2/5 turns, and the U/U' at the end of each row matches the direction of the preceding D++ or D--. [4]
Carrot megaminx scrambles are almost identical, except that the direction of the U moves at the end of each row is randomised. This increases the scramble space and very slightly improves scramble quality, but not by enough to really matter. We'll come back to this later.
In the 16 years between then and now, there have been a few claims that the Pochmann scramble format does not scramble enough. (I'm not going to bother digging up references because half of those claims will be from me.)
In May 2008, Daniel Hayes posted a statistical analysis of Pochmann scrambles to the now-defunct speedsolvingrubikscube Yahoo group. [5] His analysis involved looking at the distribution of colours on each face across a large number of scrambles (with a specified scrambling method); this gives a list of 12 (faces) × 10 (non-centre facelets) = 120 values, the standard deviation of which is used as a test statistic. The methodology is not entirely sound, but it strongly hints that very many moves will be needed to mix the pieces evenly.
(This is functionally a Pearson chi-squared test up to a scaling factor, although we cannot naïvely assume that the test statistic (squared) follows a chi-squared distribution with 11×9=99 degrees of freedom as the facelets don't freely mix under the null hypothesis. For example, you cannot just swap two facelets on the same corner piece.)
In May 2017, I used GAP to show that sufficiently long Pochmann scrambles can reach every state, and hence has the uniform distribution as a stationary distribution. [6] (I don't think this was actually proven before.)
In around May 2020 (might actually be earlier—I'm going by the save date on my document), I did a small-scale manual analysis of Pochmann scrambles, using csTimer's draw-scramble tool to save time on scrambling and re-solving. The test statistic here is the number of corner-edge pairs in the U and D F2L regions (these are easy to visually check with csTimer's scramble nets); for uniform random-state scrambles, this should be approximately Poisson distributed with mean 1/3 (twenty possible pairs, each with 1/60 chance).
For 50-move scrambles, there were 22 pairs across 20 scrambles (p-value = 0.0000021).
For 60-move scrambles, there were 6 pairs across 20 scrambles (p-value = 0.65).
For 70-move scrambles, there were 11 pairs across 20 scrambles (p-value = 0.077).
For 80-move scrambles, there were 10 pairs across 20 scrambles (p-value = 0.14).
For 300-move scrambles, there were 10 pairs across 20 scrambles (p-value = 0.14).
I don't fully trust this analysis as the pair counting was done by eye (i.e. I might have counted wrongly) and it suggests that 60-move scrambles are suddenly a lot better than 50-move scrambles. I never published these results before, but I did mention having done such an analysis in the Layer by Layer thread.
In August 2020, episode 36 of the Layer by Layer podcast was published [6], wherein Kit Clement reports on his analysis of how Pochmann scrambles move edges around. Kit's analysis ignores edge orientation (i.e. superflip looks the same as the solved state to the analysis), and finds only a small deviation in the number of moves needed to solve an edge piece in QTM.
References
[1] 2007 WCA regulations.
[2] "Megaminx scramble notation", old WCA forum. WCA archive, Internet Archive.
[3] https://www.speedsolving.com/threads/new-megaminx-scramble-notation.1603/
[4] 2008 WCA regulations.
[5] Mirror of his post. Also available from Internet Archive.
[6] https://overcast.fm/+NxG5PlYz4 The part about megaminx scrambles starts at around 36:12.
Code:
e d4 B4 d2 c4 E3 a4 f2 C2 D
F2 A B3 a2 d f2 e C b2 d4
F2 d4 f4 b c b2 c2 b4 a3 f2
a3 d4 F2 a d4 F2 A2 a2 f2 a2
f3 D d2 a4 e f3 e4 B D2 e2
d2 e4 B3 b c F2 A3 c3 d4 e2It was notorious for being hard to apply correctly and quickly. (In fact, I'm not even sure if I translated it to Twizzle notation correctly.) Nobody liked it!
This scramble format is not symmetrical across all 12 faces (although whatever bias is present is probably negligible). The scramble program (by Jaap) only tracks the previously moved face, and rejects a newly chosen face if it commutes with the previous face and comes later in the ABCDEFabcdef ordering. This is different from e.g. qqTimer's implementation, which tracks all previous moves that commute with each other, and rejects a newly chosen face iff it cancels an earlier move.
In 2007, Stefan Pochmann introduced an early prototype of the megaminx scramble format that we now use. [2][3] Key differences from modern Pochmann scrambles are that the moves can be 1/5 turns or 2/5 turns; the rotation at the end of each row is a 180° rotation around the F-DFR edge (except the last row doesn't need a rotation); and the scramble sequence consists of 100 moves (10 rows of 10 moves).
Code:
R- D- R++ D+ R+ D- R- D- R+ D-
R++ D- R-- D- R- D+ R+ D+ R-- D--
R- D+ R+ D++ R- D+ R-- D+ R+ D++
R- D+ R-- D++ R-- D-- R++ D- R-- D-
R++ D-- R-- D- R- D- R-- D+ R+ D-
R+ D- R+ D++ R++ D- R+ D-- R++ D--
R- D++ R-- D-- R-- D+ R++ D+ R+ D--
R++ D++ R- D- R- D-- R+ D++ R-- D-
R- D- R-- D-- R- D- R+ D++ R-- D++
R++ D- R++ D+ R+ D-- R- D-- R+ D+In 2008, the WCA adopted Stefan's scramble format as we know it today: 7 rows of 10 moves, all 2/5 turns, and the U/U' at the end of each row matches the direction of the preceding D++ or D--. [4]
Carrot megaminx scrambles are almost identical, except that the direction of the U moves at the end of each row is randomised. This increases the scramble space and very slightly improves scramble quality, but not by enough to really matter. We'll come back to this later.
In the 16 years between then and now, there have been a few claims that the Pochmann scramble format does not scramble enough. (I'm not going to bother digging up references because half of those claims will be from me.)
In May 2008, Daniel Hayes posted a statistical analysis of Pochmann scrambles to the now-defunct speedsolvingrubikscube Yahoo group. [5] His analysis involved looking at the distribution of colours on each face across a large number of scrambles (with a specified scrambling method); this gives a list of 12 (faces) × 10 (non-centre facelets) = 120 values, the standard deviation of which is used as a test statistic. The methodology is not entirely sound, but it strongly hints that very many moves will be needed to mix the pieces evenly.
(This is functionally a Pearson chi-squared test up to a scaling factor, although we cannot naïvely assume that the test statistic (squared) follows a chi-squared distribution with 11×9=99 degrees of freedom as the facelets don't freely mix under the null hypothesis. For example, you cannot just swap two facelets on the same corner piece.)
In May 2017, I used GAP to show that sufficiently long Pochmann scrambles can reach every state, and hence has the uniform distribution as a stationary distribution. [6] (I don't think this was actually proven before.)
In around May 2020 (might actually be earlier—I'm going by the save date on my document), I did a small-scale manual analysis of Pochmann scrambles, using csTimer's draw-scramble tool to save time on scrambling and re-solving. The test statistic here is the number of corner-edge pairs in the U and D F2L regions (these are easy to visually check with csTimer's scramble nets); for uniform random-state scrambles, this should be approximately Poisson distributed with mean 1/3 (twenty possible pairs, each with 1/60 chance).
For 50-move scrambles, there were 22 pairs across 20 scrambles (p-value = 0.0000021).
For 60-move scrambles, there were 6 pairs across 20 scrambles (p-value = 0.65).
For 70-move scrambles, there were 11 pairs across 20 scrambles (p-value = 0.077).
For 80-move scrambles, there were 10 pairs across 20 scrambles (p-value = 0.14).
For 300-move scrambles, there were 10 pairs across 20 scrambles (p-value = 0.14).
I don't fully trust this analysis as the pair counting was done by eye (i.e. I might have counted wrongly) and it suggests that 60-move scrambles are suddenly a lot better than 50-move scrambles. I never published these results before, but I did mention having done such an analysis in the Layer by Layer thread.
In August 2020, episode 36 of the Layer by Layer podcast was published [6], wherein Kit Clement reports on his analysis of how Pochmann scrambles move edges around. Kit's analysis ignores edge orientation (i.e. superflip looks the same as the solved state to the analysis), and finds only a small deviation in the number of moves needed to solve an edge piece in QTM.
References
[1] 2007 WCA regulations.
[2] "Megaminx scramble notation", old WCA forum. WCA archive, Internet Archive.
[3] https://www.speedsolving.com/threads/new-megaminx-scramble-notation.1603/
[4] 2008 WCA regulations.
[5] Mirror of his post. Also available from Internet Archive.
[6] https://overcast.fm/+NxG5PlYz4 The part about megaminx scrambles starts at around 36:12.
2. Statistical defects in Pochmann scrambles
The numerical values are either exact (written as a plain integer or fraction), exact up to rounding error (>12 significant figures), or low-precision (3-ish decimal places). Intermediate calculations were done with exact rational arithmetic where possible.
As has been suspected for many years, albeit with scant evidence, Pochmann scrambles turn out to be noticeably poor at mixing up pieces.
Consider the numbers of edge-centre pairs and corner-edge pairs. (Overlaps are counted, so a solved megaminx has 60 edge-centre pairs and 60 corner-edge pairs.)
A "flipped" edge-centre pair is one where the edge is flipped. An edge piece cannot simultaneously be part of a (proper) edge-centre pair and a flipped edge-centre pair, so the total number of edge-centre pairs and flipped pairs is at most 60.
On uniform random-state scrambles, the distribution of the number of edge-centre pairs has mean 5 and variance approximately 5.241. The number of flipped edge-centre pairs has the same distribution (but is not independent; they're weakly anticorrelated). The number of corner-edge pairs has mean 1 and variance approximately 1.000 (and is in fact very close to Poisson).
As Pochmann scrambles don't involve any scrambler state, it is easy to compute the exact expected numbers of such pairs.
| Scramble type | Edge-centre | Edge-centre flipped | Corner-edge |
|---|---|---|---|
| Random state | 5 | 5 | 1 |
| Pochmann 50 moves | 7.47281645701913710 | 2.94218572593291228 | 2.41029915644841175 |
| Pochmann 60 moves | 6.68304466811730534 | 3.47964348297554061 | 1.67687523950120673 |
| Pochmann 70 moves | 6.17719578503929442 | 3.88658011163548927 | 1.32547689082660345 |
| Pochmann 80 moves | 5.83625442828957903 | 4.18879608914996529 | 1.15675676904917577 |
| Pochmann 90 moves | 5.59912538454045698 | 4.41073229461763100 | 1.07560455837651033 |
| Pochmann 100 moves | 5.43120477659735004 | 4.57267691182530783 | 1.03651060435039594 |
| Pochmann 110 moves | 5.31111006688844347 | 4.69041938214539085 | 1.01765167866846195 |
| Pochmann 120 moves | 5.22475718369873705 | 4.77584619184983585 | 1.00854286289371304 |
| … | … | … | … |
| Pochmann 170 moves | 5.04448880058834579 | 4.95551705312917828 | 1.00022971858489459 |
It's worth noting that the convergence rates differ between edge-centre pairs and corner-edge pairs; pushing the bias under 1% takes 170 moves for edge-centre pairs and flipped pairs, but "only" 120 moves for corner-edge pairs.
The bias of excess edge-centre pairs nearly perfectly cancels out the bias of deficient flipped pairs, which may explain why Kit Clement's analysis (which ignored EO) found only a small bias.
Flipping an edge piece takes only three moves (two moves ignoring AUF), but if we restrict to 2/5 turns only, then it takes five moves (four moves ignoring AUF). As Pochmann scrambles use only 2/5 turns, it becomes harder for edges to be flipped compared to scrambling methods that can use 1/5 turns.
It appears that there is actually an isometry between megaminx edges with only 1/5 turns (as in QTM) and megaminx edges with only 2/5 turns; the distance between any two edge facelets has the same distribution in both QTM and the 2/5 turn metric. I haven't properly verified this, but it looks very closely related to the great stellated dodecahedron {5/2, 3}. This (probable) isometry does not preserve whether two edge "facelets" are on the same edge "piece", which would provide another perspective as to why it's harder to flip edges using 2/5 turns.
If, instead of having the U move and the final Dxx move be in the same direction, we also randomise the direction of the U move (as in Carrot scrambles (*), or in some non-TNoodle-equivalent implementations of Pochmann scrambles), then this slightly improves the mixing of edge pieces as 1/5 turns are now available. However, this is a tiny improvement (6.0095 pairs + 4.0410 flipped pairs with randomised U direction, compared to 6.1772 pairs + 3.8866 flipped pairs without) and does not truly fix the issue with Pochmann scrambles.
* This was written before csTimer changed its Carrot scrambles to match WCA.
It appears that there is actually an isometry between megaminx edges with only 1/5 turns (as in QTM) and megaminx edges with only 2/5 turns; the distance between any two edge facelets has the same distribution in both QTM and the 2/5 turn metric. I haven't properly verified this, but it looks very closely related to the great stellated dodecahedron {5/2, 3}. This (probable) isometry does not preserve whether two edge "facelets" are on the same edge "piece", which would provide another perspective as to why it's harder to flip edges using 2/5 turns.
If, instead of having the U move and the final Dxx move be in the same direction, we also randomise the direction of the U move (as in Carrot scrambles (*), or in some non-TNoodle-equivalent implementations of Pochmann scrambles), then this slightly improves the mixing of edge pieces as 1/5 turns are now available. However, this is a tiny improvement (6.0095 pairs + 4.0410 flipped pairs with randomised U direction, compared to 6.1772 pairs + 3.8866 flipped pairs without) and does not truly fix the issue with Pochmann scrambles.
* This was written before csTimer changed its Carrot scrambles to match WCA.
The existence of these biases can be verified with actual WCA scrambles. 91 megaminx scrambles were used for Rubik's WCA World Championship 2023. (12 groups for first round, 1 group for final; 7 scrambles per group.) Among these 91 scrambles, there were a total of 561 edge-centre pairs (6.16 average), 337 flipped edge-centre pairs (3.70 average), and 119 corner-edge pairs (1.31 average). Under the null hypothesis of the scrambles being sampled from the uniform distribution, these correspond to p-values of 0.00000068 (at least 561 pairs), 0.000000037 (at most 337 pairs) and 0.0028 (at least 119 pairs) respectively, using a normal distribution approximation for the first two and Poisson distribution approximation for the third.
If we reorient the puzzle to initial scramble orientation after applying a Pochmann scramble, we can also ask: which piece-location combinations show up too frequently/infrequently? These are the biggest deviations from uniformity for the edge pieces:
U-F (white-green) edge solved: 1/60 + 0.0064448185252294699 (~39% too likely)
U-BL (white-yellow) edge solved: 1/60 + 0.0064448185252294699 (~39% too likely)
F-DFR (green-cream) edge solved: 1/60 + 0.0061514259936004502 (~37% too likely)
BL-DB (yellow-lime) edge solved: 1/60 + 0.0061514259936004502 (~37% too likely)
For each of the 60 possible corner-edge pairs, we can reorient the puzzle so that the edge is in a fixed location (say, U-L) and find the corner (say, U-L-BL). These are the biggest deviations from uniformity:
U-L-BL (i.e. formed pair): 1/60 + 0.0054246148471100574 (~32% too likely)
L-BL-U (i.e. twisted corner): 1/60 − 0.00093587418368997878 (~5.6% too unlikely)
BL-U-L (i.e. twisted corner): 1/60 − 0.00093587418368997878 (~5.6% too unlikely)
B-BR-BL (i.e. BL2' away from formed pair): 1/60 + 0.00053037747599415802 (~3.2% too likely)
DBL-B-BL (i.e. BL2 away from formed pair): 1/60 + 0.00053037747599415802 (~3.2% too likely)
One useful statistic we can measure here is the difference between the most likely combination and the least likely combination. Another potentially useful statistic is the earth mover's distance (EMD) from the uniform distribution; this measures how many moves we need on average to uniformise the piece's location distribution.
EMD is more sensitive to deviations from uniformity than just looking at average move count to solve a piece. If the average move count differs from uniform random state's average move count by x moves, then the EMD will be at least |x| moves. (EMD is always nonnegative.)
Consider the distribution of the edge pieces under QTM. For an ideal random-state scramble generator, it takes 186/60 = 3.1 moves on average to solve one edge piece by itself.
Now consider a scramble generator that always returns superflip; every edge piece is always 3 moves away in QTM, so the average distance is exactly 3 moves and the deviation is −0.1 move.
The EMD, however, is the same as for a scramble generator that always returns the solved state; each edge piece is always 3.1 moves away from being uniformly distributed, so the EMD is 3.1 moves.
For comparison, edge pieces in 50-move Pochmann scrambles have average distance 3.000080 moves, 0.099920 move deviation. Our always-superflip scramble generator is as good as 50-move Pochmann scrambles if we measure scrambledness by average distance, but if we measure scrambledness by EMD, it's as bad as not scrambling at all.
Put another way, EMD cares about the metric space structure of the underlying set, whereas looking at only the distance to solved forcibly linearises the metric space with one reference point, destroying its original metric and the symmetry between all the points.
Now consider a scramble generator that always returns superflip; every edge piece is always 3 moves away in QTM, so the average distance is exactly 3 moves and the deviation is −0.1 move.
The EMD, however, is the same as for a scramble generator that always returns the solved state; each edge piece is always 3.1 moves away from being uniformly distributed, so the EMD is 3.1 moves.
For comparison, edge pieces in 50-move Pochmann scrambles have average distance 3.000080 moves, 0.099920 move deviation. Our always-superflip scramble generator is as good as 50-move Pochmann scrambles if we measure scrambledness by average distance, but if we measure scrambledness by EMD, it's as bad as not scrambling at all.
Put another way, EMD cares about the metric space structure of the underlying set, whereas looking at only the distance to solved forcibly linearises the metric space with one reference point, destroying its original metric and the symmetry between all the points.
In the following table, we measure the EMD between an edge piece's location distribution and the uniform distribution in two metrics: QTM and 1.5TM. The EMD is calculated for all 30 edge pieces individually, with the average and maximum values out of these 30 EMD values reported below.
| Scramble type | Average EMD (QTM) | Maximum EMD (QTM) | Average EMD (1.5TM) | Maximum EMD (1.5TM) |
|---|---|---|---|---|
| Random state | 0 | 0 | 0 | 0 |
| Solved state | 3.1 | 3.1 | 2.70833333333333333 | 2.70833333333333333 |
| Pochmann 50 moves | 0.26140554593191882 | 0.29344564597119446 | 0.26137747363301654 | 0.29344564597119446 |
| Pochmann 60 moves | 0.18818144125649014 | 0.21094218139096728 | 0.18818144125649014 | 0.21094218139096728 |
| Pochmann 70 moves | 0.13581148478631167 | 0.15215559650067379 | 0.13581148478631167 | 0.15215559650067379 |
| Pochmann 80 moves | 0.098131894782159555 | 0.10990211248412987 | 0.098131894782159555 | 0.10990211248412987 |
| Pochmann 90 moves | 0.070951927518293159 | 0.079442020134612647 | 0.070951927518293159 | 0.079442020134612647 |
| Pochmann 100 moves | 0.051318495115595434 | 0.057448050928054211 | 0.051318495115595434 | 0.057448050928054211 |
| Pochmann 110 moves | 0.037124639992843060 | 0.041552846810364668 | 0.037124639992843060 | 0.041552846810364668 |
| Pochmann 120 moves | 0.026858743684531565 | 0.030059517156821018 | 0.026858743684531565 | 0.030059517156821018 |
| Pochmann 130 moves | 0.019432311225919008 | 0.021746738420776168 | 0.019432311225919008 | 0.021746738420776168 |
| Pochmann 140 moves | 0.014059527888463373 | 0.014059527888463373 | 0.014059527888463373 | 0.014059527888463373 |
| Pochmann 150 moves | 0.010172306896354342 | 0.011383156661994253 | 0.010172306896354342 | 0.011383156661994253 |
| Pochmann 160 moves | 0.0073598579919414643 | 0.0082359184458418558 | 0.0073598579919414643 | 0.0082359184458418558 |
| Pochmann 170 moves | 0.0053250023738168131 | 0.0059588542812461644 | 0.0053250023738168131 | 0.0059588542812461644 |
(Observe that EMD in QTM and in 1.5TM coincide for long-enough Pochmann scrambles; this does not happen with other scramble formats. This peculiarity appears to be caused by Pochmann scrambles using only 2/5 turns.)
This doesn't really fit anywhere else, but it's worth mentioning that the chance of getting a "square" (a block consisting of a centre, two adjacent edges, and a corner between them) is supposed to be 1/696 with random-state scrambles, but is nearly thrice as common at around 1/240 with 70-move Pochmann scrambles.
3. Alternative scrambling formats
(None of these names are set in stone. Feel free to come up with better names. In fact, also feel free to come up with your own alternative scrambling formats!)
Must-haves:
- Better than 70-move Pochmann scrambles on reasonable mixedness metrics.
- Can be easily executed "blind", i.e. without looking at the puzzle.
- Scramble space cannot be too small (at least 10^18).
Nice-to-haves:
- No weird notation.
- Non-randomised orientation.
- At least as good as 100-move Pochmann scrambles on reasonable mixedness metrics (or at most slightly worse).
I've spoken with Lucas Garron regarding orientation randomisation (he's for, I'm against). Randomising orientation practically means that one-move misscrambles by doing a rotation or a wide move the wrong way will lead to a mostly-different-looking scramble state, which brings up fairness concerns. Orientation randomisation is, however, a very useful way to ensure that every face gets roughly equally scrambled.
3.0. Random-state scramble
This wasn't a thing at the time I initially wrote the first draft of this post (mid 2024), but it is now late 2025 and at least three people have coded reasonably efficient megaminx solvers. Move counts seem to be around 80-90 moves for all of our solvers.
The ones that use subgroup reduction (Alexander Botz's, Chen Shuang's) generally have the issue that the initial part of the solution involves solving F2L at the bottom, with a lot of bottom-hemisphere moves. I don't think either of these two solvers have been publicly released yet, but if you want to get a feel of what it looks like, see csTimer's kilominx random-state scrambles:
Code:
BL DBR2' B2 DBR' D2 B2 DBR' BR R U2 BR2 R2 BR2' BL2
U F U2' F' U L2' U L2 F2' U2' F' U'Mine instead mimics my kilominx solver, by using U, L, F, R, BR, BL and flip ("x2" in Twizzle): get the bottom-layer pieces out of the top, flip, solve F2L, flip again, solve the rest. Also not publicly released yet (because it's not finished: it still requires manual fiddling for the solution to actually work), but the source code is available on request. Usage of BL and BR moves is deprioritised by having the back blocks solved earlier, so the majority of the solution is ULFR 4-gen.
Code:
BL2 U2 L R' flip
L U' BL U R2' U' BR2 U2 BR2 U2 L' R BR2' BL2'
U L2 R2 F2' L2 U2' F2' L U' F L2' F BR2 BL2' BR flip
F' BL BR' U2' R F2' BL2' U2' BR2 U' BR BL'
L2' U L R2 F2 R2 F2' U R2' U2 F' L2 U2 L' R
F' R2 U' R' U' R U' R2' F' L F2' L' R F2' R U R' U L R' F L' R U'This took me 42.20 seconds to apply (correctly, first try), which we can use as a benchmark for scrambling formats: if it takes more than 40-ish seconds, we might as well just use random-state scrambles.
One major issue with my current solver (besides not being finished yet) is that it has relatively extreme resource requirements (~3 GB RAM) and in spite of that is still quite slow for the final phase. Part of this is that I just haven't bothered optimising it yet (it can easily go down to ~500 MB), but it's partially also inherent to the current design. Introducing an extra phase would reduce the RAM requirements a lot in exchange for (maybe?) worsening efficiency by 3-4 moves.
The 84-move solution above was using the first solution found for every phase; searching multiple solutions per phase should significantly reduce average move count, which ought to cancel out this (3-4)-move worsening.
The 84-move solution above was using the first solution found for every phase; searching multiple solutions per phase should significantly reduce average move count, which ought to cancel out this (3-4)-move worsening.
3.1. Opposites
Code:
U D2' Lv U2' D' BRv U2' D Fv U2 D2' Rv U' D2' BRv
U' D' BLv U2' D2 Lv U2 D Fv U2 D2 BLv U D' Rv
U2' D2 BRv U D2' Fv U2 D' Fv U D2 Fv U2 D' Lv
U2' D BRv U' D Lv U' D Fv U D2' Lv U' D2' BRv
U2 D' BRv U D2' BLv U D' Fv U' D' Lv U2 D BLv
U' D2' BRv U2' D BRv U2 D2' Rv U' D2 Fv U2 D2 Rv
U2 D2' Fv U2' D BLv U2 D' Fv U' D2 Lv U2 D2 BLvDo a random U move and a random D move (where "D" is the face opposite of U), then rotate a random non-UD axis to UD. Repeat.
This one is more of a proof of concept than something that's human usable. It's very simple and mixes the pieces very well, but is absolute hell to execute. I am not recommending this to replace Pochmann scrambles.
The moves can also be written without rotations.
Here's a square-1-like notation for the first two rows of the above scramble sequence. Here, "A(x,y)" means to turn the A face by x and the opposite face by y.
Code:
U( 1,-2) BL(-2,-1) BR(-2, 1) U( 2,-2) R(-1,-2)
BR(-1,-1) U(-2, 2) R( 2, 1) BR( 2, 2) L(-1, 1)3.2. FBy
Code:
F' B2 y F2' B y F B2 y F B y F2 B y
F' B y F2 B2' y F' B2' y F B y F' B2 y
F2 B y F2' B y F2 B' y F' B2 y F2' B' y
F B y F' B y F2 B2' y F' B2' y F2' B y
F' B2' y F' B2' y F B2 y F2' B2' y F2 B2' y
F2' B2' y F B y F2' B y F2' B' y F2 B2' y
F2' B' y F2 B y F' B y F2' B' y F2 B2' yI actually came up with this before "Opposites". Same idea, but the moves are on the F and B faces with a y rotation after every pair of moves. The U (white) and D (grey) faces are never turned in this scramble format. All solvable positions are still reachable eventually (verified with GAP).
This is a bit better than Opposites at breaking up pairs and mixing up the pieces.
I have not found a reasonable way of executing this format accurately and quickly. It did, however, inspire the next one…
3.3. RFLy
Code:
R' FL y R2' FL y R' FL2 y R2' FL2 y R2' FL' y
R2' FL' y R FL2 y R FL' y R FL y R FL2 y
R2 FL y R' FL2 y R2' FL' y R2' FL' y R2' FL' y
R2' FL' y R2' FL2 y R' FL2' y R2 FL y R2' FL' y
R2' FL2' y R' FL y R FL' y R FL y R' FL' y
R FL y R' FL2 y R FL y R' FL' y R' FL2 y
R' FL y R2' FL y R' FL' y R FL' y R2' FL yThis is mostly self-descriptive: do a random R move, do a random FL move, y rotate, repeat.
I do this with wrist turns for the R moves and left thumb pushes for the FL moves. Unfortunately, restricting the FL face to 1/5 turns has a huge negative impact on scramble quality; as a compromise, we bias towards 1/5 turns (2/3 chance of FL or FL'; 1/3 chance of FL2 or FL2').
After some practice, I can execute 70-move scrambles in around 38 seconds.
Potential downside: The heavy left thumb usage during scrambling may lead to RSI.
3.4. Roundabout
Code:
BL BR R F L U2' BL BR R' F' L' flip
BL BR' R F' L U BL' BR R F L flip
BL' BR R' F' L' U2' BL' BR' R F L flip
BL' BR' R' F' L U2 BL' BR' R F' L' flip
BL' BR' R F' L' U' BL' BR' R F' L flip
BL BR R' F L' U2 BL' BR' R' F' L flip
BL BR R' F' L U BL' BR' R F' L'Do random 1/5 turns on the BL, BR, R, F, L faces in that order, then a random U move, then random 1/5 turns on those five faces again, then flip the puzzle over.
In practice, the "flip" isn't executed in isolation, but together with the next row's BL and BR moves.
Using both 1/5 and 2/5 turns seems to improve mixing, but at the cost of making the ergonomics much worse.
Looking solely at the number of edge-centre pairs and corner-edge pairs, this scramble format fares much better than Pochmann scrambles, even when normalised for similar scrambling time. However, for shorter scramble lengths, there is an asymmetry in how much the pieces are scrambled – the bottom hemisphere's pieces are effectively scrambled for 11 moves less.
It's still asymptotically better than Pochmann scrambles in the long run, but at reasonable scramble lengths, it's worse.
3.5. Pochmann + F
Code:
R++ D-- R-- D++ F' R++ D-- R++ D-- F' R-- D++ R++ D-- U'
R-- D++ R-- D++ F R++ D-- R++ D++ F' R-- D-- R-- D++ U
R-- D-- R-- D-- F R++ D++ R-- D++ F' R++ D-- R++ D-- U'
R++ D-- R-- D++ F' R-- D++ R++ D-- F' R-- D-- R++ D++ U
R-- D++ R++ D++ F' R-- D++ R++ D-- F' R-- D++ R++ D++ U
R-- D++ R-- D-- F R-- D++ R++ D-- F' R++ D++ R-- D++ U
R-- D++ R++ D++ F R++ D++ R++ D++ F' R++ D++ R++ D-- U'Pochmann scrambles, but with intercalated F moves. Pochmann scrambles leave the UL corner-edge-corner bar untouched most of the time, but by introducing F moves, we regularly break up this bar. Not clear what a good balance of F moves is, but it turns out to not matter too much because there's something better.
3.6. Pochmann + FB
Code:
R-- D-- R-- D++ R++ D++ R++ D-- F' BL
R++ D-- R++ D-- R++ D++ R++ D++ F' BL
R++ D++ R++ D++ R++ D++ R++ D++ F BL
R-- D-- R-- D++ R-- D++ R++ D++ F' BL'
R++ D-- R++ D-- R-- D++ R++ D-- F BL
R++ D++ R-- D++ R++ D++ R++ D++ F BL'
R++ D++ R++ D++ R-- D++ R-- D++ F' BLInstead of U moves at the end of each row, we do random F and BL moves instead. For ergonomics reasons, and also for EO reasons, these are restricted to 1/5 turns.
Assuming a standard colour scheme, the white-purple edge will always be in the UL position. Even if one drops the puzzle mid-scramble, it is always possible to pick up the puzzle in the correct orientation and resume.
This is what I've been using for practice, except always doing F and BL' instead of randomised directions. It's a bit slower to do than Pochmann scrambles, but not by too much: standard Pochmann takes me ~21 seconds, the always-(F BL') variant takes me ~23 seconds, and the randomised F* BL* variant takes me ~28 seconds.
Note that even the always-(F BL') variant is much better than Pochmann, and in fact it seems to have (very slightly) better stats than the randomised F* BL* variant. I'm not sure how generalisable this is.
Filtering these scrambles to those that end up in initial scramble orientation (as is traditionally done for megaminx FMC) will always lead to a scramble with the UL edge solved. One workaround is to tack a random U/U' at the end of each row (just like normal Pochmann scrambles) so that the UL edge is no longer fixed.
Here are the tables from above, with Pochmann + FB added. As you can see from the data, this is substantially better than 70-move Pochmann scrambles, and even somewhat better than 100-move Pochmann.
| Scramble type | Average EMD (QTM) | Maximum EMD (QTM) | Average EMD (1.5TM) | Maximum EMD (1.5TM) |
|---|---|---|---|---|
| Random state | 0 | 0 | 0 | 0 |
| Solved state | 3.1 | 3.1 | 2.70833333333333333 | 2.70833333333333333 |
| Pochmann 70 moves | 0.13581148478631167 | 0.15215559650067379 | 0.13581148478631167 | 0.15215559650067379 |
| Pochmann 130 moves | 0.019432311225919008 | 0.021746738420776168 | 0.019432311225919008 | 0.021746738420776168 |
| Pochmann 140 moves | 0.014059527888463373 | 0.014059527888463373 | 0.014059527888463373 | 0.014059527888463373 |
| Pochmann + FB 7 rows (84 moves) | 0.018217639733735790 | 0.020741899841566394 | 0.018208910285960532 | 0.020741899841566394 |
| Scramble type | Edge-centre | Edge-centre flipped | Corner-edge |
|---|---|---|---|
| Random state | 5 | 5 | 1 |
| Pochmann 70 moves | 6.17719578503929442 | 3.88658011163548927 | 1.32547689082660345 |
| Pochmann 80 moves | 5.83625442828957903 | 4.18879608914996529 | 1.15675676904917577 |
| Pochmann 90 moves | 5.59912538454045698 | 4.41073229461763100 | 1.07560455837651033 |
| Pochmann 100 moves | 5.43120477659735004 | 4.57267691182530783 | 1.03651060435039594 |
| Pochmann 110 moves | 5.31111006688844347 | 4.69041938214539085 | 1.01765167866846195 |
| Pochmann 120 moves | 5.22475718369873705 | 4.77584619184983585 | 1.00854286289371304 |
| Pochmann + FB 7 rows (84 moves) | 5.15427048150863333 | 4.85036450055896585 | 1.02830782369943139 |
3.7. Pochmann with rejection sampling
Generate the scramble sequences as usual, but reject the resulting scrambles that are too easy (or too hard!) and reroll for a new scramble.
Rejection sampling is a general technique for morphing one distribution into another, with fairly lax preconditions. As long as something you want out of the target distribution isn't outright impossible in the source distribution, it's always possible to use rejection sampling to accomplish this morphing.
Rejection sampling was previously proposed by Roman Strakhov for shortening big cube scrambles; here the issue is instead that 70-move Pochmann scrambles are already too short, with glaring statistical defects, so we look to use rejection sampling to bring them up to snuff. However, rejection sampling has major issues:
1. We can't actually apply the standard form of rejection sampling because most legal states aren't even reachable from 70-move Pochmann scrambles. Instead, we look at certain aspects of the scrambles, such as the quantity of edge-centre pairs and edge-centre flipped pairs. The problem then becomes…
2. The source and target distributions are not known exactly and have to be empirically estimated. Rejection sampling does not seem to be robust against inaccurate knowledge of the source and target distributions; if the average number of rejections is small, this is not a huge problem, but frequent rejections can amplify inaccuracies. This is an issue because…
3. A large number of rejections will be needed if the distributions differ a lot. The average number of raw scrambles to generate per output scramble is given by max((pmf of target distribution) / (pmf of source distribution)). (Division here should be interpreted as pointwise division.) If we bin the states by the number of edge-centre pairs (capped at 12) and flipped pairs (also capped at 12), so there are 13² = 169 bins in total, this quantity works out to around 11.3 raw scrambles per output (with huge error bars).
4. Rejection sampling can only fix exactly what we're filtering for. For instance, if we use rejection sampling to fix the excess edge-centre pairs, the resulting scrambles will still be deficient in edge-centre flipped pairs. If we filter for both edge-centre pairs and flipped pairs, then we still have corner-edge pair bias (they're still around 31-32% too likely). It's possible to repeat this but this seems like a never-ending unwinnable battle: what about 1-move pairs? What about corner-edge twisted/flipped pairs? What about 1 move to those? Etc. etc.
5. This is almost certainly not robust against misscrambling. If R++ is replaced by R−− or vice versa (or D++ with D−−) near the middle, that results in a huge change in the puzzle state, which likely invalidates what the rejection sampling algorithm is actually trying to filter. Quite possibly, misscrambles will have biases that are more like unfiltered scrambles. I have not investigated this.
I'm no statistician, so I don't know how fixable these issues are. However, it seems complicated enough that changing the scramble format is a much more attractive option.
4. Conclusion
In lieu of any better suggestion, I strongly recommend switching to Pochmann + FB (either the original randomised F* BL* variant or the fixed F BL' variant) with 7 rows of 12 moves as an interim measure. If we take 99% as our "scrambledness" benchmark, then 7 rows Pochmann + FB still isn't good enough and we will eventually have to upgrade our scrambling method again. (There's more I want to talk about regarding this, but, you know! Deadlines!)
Viability of random-state scrambling may need to be revisited.
Code used for the computations. It's about as jank as you'd expect research code to be, but better to have crap code that you can use to reproduce the results than none at all. There are a few other scramble formats I experimented with in there that I didn't write about in this post.
Last edited:
