Josh Mermelstein

Axles puzzle

Sun, 20 Jul 2025 00:00:00 +0000

This is a post about axles, a game I put together with help from Gemini. This post might make more sense if you go play a round before you read it.

Background

In 2024, I saw a post on the twisty puzzles forum about the Peterhoff-Smolensk puzzle. I thought it was a really nice idea, and filed it on my mental “I should think more about this” list.

Simulator in Rust

I didn’t know what specifically I wanted to do, just that I wanted to do something. My two main ideas were to make 3d printed version of it, and to make some kind of interactive digital version of it. I decided to start with something in between - an analysis tool to help me figure out what sort of puzzles I wanted to make.

As an experiment, I asked Gemini to write the first version of this simulator in Rust (but on a square grid instead of a hex grid). The results were better than I expected! With minimal edits, I was able to input a hardcoded goal configuration, and then run the code to answer questions like “what start is furthest from the goal state?”

I modified the code to try random 3x3 starting configuration and print cases where the furthest node was especially far away. The results were impressive, the AI generated code found cases like this one, where these two states were 36 moves apart.

Goal:
|↑ ^><|  |↑ >v|  |↑ |
|↑ ^>v|  |↑ v|  |↑ ^>|
|↑ ><|  |↑ >|  |↑ ^|

Start:
|↑ ^><|  |↑ >v|  |→ |
|← ^><|  |↑ v|  |↑ ^>|
|→ ^v|  |↑ >|  |↑ ^|

Interactive Simulator

I cut out some scraps of paper to try to play with this puzzle, but found it a little annoying to keep everything aligned, so I turned to Gemini again, and asked if it could make the code interactive.

I was expecting some sort of stdin/stdout interface, where I could give moves to the rust code one at a time. To my surprise, Gemini rewrote the simulator in javascript, and opened an interactive gui where I should interact with the js that it wrote. Parts of it were a little clunky, but it crystallized my goals in my head. I wanted to polish this javascript version to make it easy for others to play with these puzzles.

GUI stuff

Polishing the gui wasn’t that hard. The AI had done a lot of the bits that I’m inexperienced with (css, event handling…), and I just had to edit them to work the way I wanted. Where possible, I did this using more AI prompting; though there were a few cases where the AI did quite a bad job and I ended up reverting its changes and making them manually.

It got fixated on drawing the dots on each cell using css pseudo-elements, and I’m not sure that approach is viable at all.

Puzzle generation

When generating the goal state, it’s undesirable if there’s a loop of blockages, such that A blocks B blocks C blocks D blocks A. When this happens, none of those axles can turn, which means that much of the puzzle isn’t intractable.

To prevent this problem, I came up with the following:

assign each axle a random and unique id between 1 and num_axles
(treat out-of-bounds as having some arbitrary id, like num_axles/4)

for every position where it's possible to place a dot:
    if a lower id would block a higher id - do nothing
    if a higher id would block a lower id, add a dot with X% probability.
    if any axle has all four blockers, that's boring, remove one blocker.

I’m quite pleased with this approach. It is computationally cheap, and scales linearly with the number of axles; and it’s easy to convince myself that this never generates those undesirable loops of blockers.

Additional modes

Once I had that working, I decided to add some additional modes. By tweaking the probability with which blockers are generated, I could make an “easy” mode with sparser boards. And then I added support for diagonal blockers, and called that “Hard” mode.

Closing thoughts

My favorite part of this project is the speed and output of puzzle generation. The quality of puzzles is good enough that I don’t feel the need to add human-authored ones.

I’m also quite happy with the usability. I watched a few friends trying it out, and they seemed to find the GUI intuitive, in a way that let them engage with the puzzle’s rules.

This was my first time using AI in this way and I found the experience fascinating. It was quite good at some things, but also got hopeless stuck on others. I think the best part was the speed with which it got me something I could interact with. That helped me refine my goal, and saved me a few hours.

Future work

The author of Peterhoff-Smolensk recently published a 3D version of their idea, which they call the Bomzh Cube

I think this idea is fascinating as well, and that it would be neat to have a digital simulator for it. I would need to learn quite a lot (or lean even harder into AI-assisted programming).

Bandaged Cube Diameter

Tue, 20 Dec 2022 00:00:00 +0000

Background

Readers of my blog may recall a tool I released in 2020 called bandaged cube explorer. It used javascript to visualize the state space of bandaged 3x3x3 puzzles.

I recently got an email from someone who had used it to look at 0x2000402849B5E. They pointed out that this graph has some vertices that are extremely far away from the starting configuration, and said “I wonder if there are bandaged puzzles with configurations that take even more moves to reach.”

I found this question fascinating and spent some time generating and analyzing data. I’d like to share some of my findings with you here.

Why this is interesting

In my 2020 blog post, I wrote “When I first tried to get into bandaged puzzles, I found a few docs online containing collections of named configurations […] What they both lacked was guidance on what kind of experience to expect when solving each puzzle”. To this day, I still don’t have a satisfying way to predict solving experience from bandaged signature.

Looking at the max distance between vertices has the potential to help with this. I suspect that puzzle where this metric is large contain long, highly constrained paths through the shape space, and will be a different solving experience from puzzles where this metric is small. To be clear, this is not about the difficulty of the solve, it’s about the experience of the solve, and the kinds of tools a solver will need to develop.

Also, I think no one has computed these numbers before, and that appeals to me as well.

Definitions

There are two common ways to measure how far apart two configurations are. In QTM (quarter turn metric), every quarter turn counts as one move. In HTM (half turn metric), a double turn of a single face only counts as one move. There are a few other interesting distance metrics but we will ignore those for this blog post.

In graph theory, we have a few terms to explain how far apart things are. A vertex’s eccentricity is the maximum distance from it to any other vertex. The vertex with the smallest eccentricity is called the center and its eccentricity is called the radius. Note that a graph may have more than one center. The largest eccentricity in a graph is called the diameter.

Techniques

Bandaged cube graphs are pretty tame by graph theory standards. All edges are bidirectional and have equal weight. This means we can do a breadth first search from each vertex in a graph and easily filter for the minimum and maximum eccentricities. As a bonus, we’ll get a representative example for each of those.

One useful optimization I found was to observe that bandaged configurations that only differ by orientation/mirroring must have the same eccentricity. Checking whether two cubes are the same modulo orientation is computationally cheap compared to breadth first search on most graphs so this improved runtime dramatically.

I applied this procedure to all 3559 bandaged configurations listed here and containing >1 vertex. Both the source code and the raw data are available on my github.

With all that out of the way, I’d like to share a few bandaged 3x3x3 configurations that are special in some way.

Cubes with very large diameter and radius

Largest

0x1003FE80000423 has by far the largest diameter, in both QTM and HTM.

Note that the ‘x’ over the white center means that this face is never allowed to turn. In QTM, 0x2003FD00041830 and 0x1003F680104444 are a whopping 167 moves apart (note that these two are mirror images of one another). This cube also has the largest diameter in HTM, 127.

I was quite surprised to see how small the graph for this configuration is. It has just 3780 vertices. Some configurations have over 20x as many vertices and yet have dramatically smaller diameters! (note: it’s still large enough to lag bandaged-cube-explorer. In this blog post, I’ll only deeplink to graphs that are small enough to render nicely on mobile).

At first, I found the bandaged white center on this cube a little unsatisfying, because my usual tools for playing with bandaged 3x3x3 puzzles (a cubetwist bandaged kit or the Magic Cube app) both can’t handle that. Then I checked the diameter of this configuration with the white center unlocked and found that it does not change!

Second largest

The configuration with the second largest diameter in both QTM and HTM is 0x83fe04000c21.

This configuration has a QTM diameter of 120 (example 0x83BE04021182 to 0x188c30c4204441) and an HTM diameter of 96.

This configuration also has a surprisingly small graph. It has a mere 2704 vertices.

Top 10 (QTM)

After this, QTM and HTM disagree about which configurations are largest. Here are the remainder of the top 10 in QTM:

0x10000080800C63 (QTM: 117, HTM: 73)
0x21109308C00C46 (QTM: 115, HTM: 90)
0x108430C40007A3 (QTM: 113, HTM: 92)
0x1003DA80000423 (QTM: 110, HTM: 90)
0x1084308620063D (QTM: 107, HTM: 79)
0x10039E80000403 (QTM: 101, HTM: 83)
0x1084308420063D (QTM: 101, HTM: 75)
0x21000102000C43 (QTM: 100, HTM: 59)

Top 10 (HTM)

And here is the rest of the top 10 in HTM:

0x108430C40007A3 (#5 above)
0x21109308C00C46 (#4 above)
0x1003DA80000423 (#6 above)
0x10039E80000403 (#8 above)
0x1084308620063D (#7 above)
0x72920080007F (QTM: 95, HTM: 77)
0x1084308420063D (#9 above)
0x139200800C1C (QTM: 94, HTM: 75)

The vertex counts of all these graphs are lower than I expected. The largest one is 0x1003DA80000423 with 7586 but most are well below 5000. To get a better sense of the data, I made this scatter plot of diameter (QTM) vs vertex count.

For more information on these configurations, such as examples of pairs of vertices that are the maximum distance apart, see the raw data.

Comparing QTM diameter to HTM diameter

Another thing I found surprising, was the different between QTM diameter and HTM diameter in configurations like 0x21000102000C43 (100 vs 59). Here’s a scatterplot of the raw data on these two measures:

High QTM/HTM

QTM diameter can never be larger than 2x the HTM diameter since each half turn can be replaced by two quarter turns. Over 50 configurations achieve the maximum of HTMx2 = QTM. The two that stand out to me are 0x8000802E3401 and 0x8000842FB421. Both have 110 vertices and a QTM diameter of 12. I suspect they’re actually the same puzzle in disguise as two different configurations.

Low QTM/HTM

QTM diameter can never be lower than HTM diameter. Almost 70 configurations have an equal QTM diameter and HTM diameter. This means that half turns are not useful when traveling between antipodes.

The largest of these by diameter (17) is a tie between 0x30138380002D and 0x80018620002D. The largest of these by vertex count are 0x180200021 (402, and a diameter of 15) and then 0x10000000000002, (240, and a diameter of 5).

A few other configurations that stood out to me are: 0x10000084018421 (2540 vertices, QTM diameter 18, HTM diameter 17) 0x108401843DCC21 (1130 vertices, QTM diameter 64, HTM diameter 56)

Diameter/Radius

In a normal circle, the diameter is definitionally 2x the radius. In undirected graphs like ours, the diameter is capped at 2x the radius but can be smaller than that. Here’s a scatterplot of the overall relationship between the two:

Equal diameter and radius

There are ~70 puzzles where diameter and radius equal in QTM. By radius, the three largest ones are 0x30000010048883, 0x20108000000C03, and 0x30000000040203. All three have a QTM radius and diameter of 15. Amazingly, all three of these are familiar to me. The first one is the subject of a previous blog post of mine. The other two are both mentioned at the end of that blog post as potentially related configurations!

Nearly equal diameter and radius

If we expand our search to puzzles where the diameter is only slightly larger than the radius then we can find some other puzzles whose graph forms one big loop.

One that jumped out at me was 0x80408B40DC7A1 (diameter 47 QTM, radius 38 QTM). This puzzle turns out to be the Maze-300 cube by André Kutepow (Isaev). It is the bandaged 3x3x3 with the largest known god’s number (301 QTM).

A few others that seem potentially interesting are 0x1108100440843 (diameter 48 QTM, radius 39 QTM) which has a beautiful spread out graph with lots of loops. Also 0x10843086218C21 (diameter 53 QTM, radius 42 QTM) and 0x139E0090002D (diameter 62 QTM, radius 46 QTM).

Is vertex count a good predictor of diameter?

Nope!

There are many examples of graphs with relatively low vertex count but large diameter, e.g. 0x21000100008C43 (726 vertices, QTM diameter of 95) and 0x100C00808005AD (482 vertices, 73 QTM diameter).

There are also plenty of examples of graphs with a high vertex count but relatively low diameter, such as 0x8000000804 (a.k.a “3 stripes”) (1296 vertices, QTM diameter of 8), and 0x20008000000806 (7344 vertices, QTM diameter of 14).

Looking at diameter / vertex count

I was hoping that this ratio might help me find some interesting puzzles but the results were disappointing. Configurations where this metric was high, such as 0x30080200000603 and 0x824810800C23 tended to have extremely constrainted graphs, (click through to see them). Their graphs have almost no branching and I suspect these puzzles can barely scramble.

Puzzles were this metric was small were ones with the largest vertex counts, and didn’t have particularly interesting diameters.

Closing thoughts

The maze 300 cube has a QTM diameter of only 48, many of the puzzles discussed in the blog post have a dramatically larger diameter. I wonder if one of these will be able to take the record for the configuration with the largest known god’s number.

If you find such a configuration, or you find another intersting feature in the data, please send me an email and let me know!

More thoughts - cube orientation

(This update was published on Jan 14, 2023.)

A user on the twisty puzzles forum raised an interesting point. The way my code computes graphs’ properties assumes that the orientation of the puzzle is fixed. This does not map nicely to how people visualize and solve puzzles. If two states differ only by oreintation, then a solver can use the same approach to both by just rotating the cube.

I re-ran my analysis but modified to consider two configurations the same if they only differ by orientation (or mirroring). I’ll start by looking at the results in isolation, and then do some comparison between these results and my previous results where cube orientation was considered.

When we ignore orientation, a few graphs shrink down to a single vertex and a diameter of 0. In case where dividing by 0 would be inconvenient, I’ll be ignoring these configurations instead.

If you’d like to play with the raw data, I made it available on my github. Putting all of it in one .csv felt unwieldly so I split this data into its own file. If you’d like to merge them, the rows are in the same order in both.

Largest vertex count

This has nothing to do with graph diameters but I’ve never seen these results posted before so I might as well mention them here. These are the four configurations with the largest vertex counts if we ignore orientation.

0x10840080800423 (21490 vertices) [3rd most vertices when considering orientation]
0x10041080200421 (18551 vertices) [7th most vertices when considering orientation]
0x3DA00000C08 (16894 vertices) [10th most vertices when considering orientation]
0x39E00000420 (15134 vertices) [13th most vertices when considering orientation]

Largest Diameter (ignoring cube orientation)

Unsurprisingly, many of the puzzles with a large diameter are familiar to us from earlier in this post. The puzzles with the largest diameter in QTM are:

0x108430C40007A3 (113 QTM, 92 HTM) [5th largest QTM diameter with orientation considered]
0x1003FE80000423 (103 QTM, 76 HTM) [1st largest QTM diameter with orientation considered]
0x1003DA80000423 (99 QTM, 89 HTM) [6th largest QTM diameter with orientation considered]
0x500180800C3D (91 QTM, 72 HTM)
0x210B9100000863 (91 QTM, 71 HTM)
0x10039A800005AD (86 QTM, 69 HTM)
0x73920080007F (86 QTM, 68 HTM)
0x1084308620063D (84 QTM, 64 HTM) [7th largest QTM diameter with orientation considered]
0x18C400C7A00401 (84 QTM, 66 HTM)
0x3DA00000C60 (83 QTM, 66 HTM)

Several puzzles on this list (#1, #4, #5, #6, #7, #9) have no self-symmetries, so their graphs are the same whether or not we consider orientation. The remaining puzzles all had 2x as many vertices before we stopped considering orientation.

0x10039A800005AD (#6) appeals to me for some reason. It’s graph is slightly too large to link but the shape is pretty fun; one very big loop and then a complex appendage coming off of it. It has quite a few “normal” edges which makes me think the solve will have some fun subproblems.

0x73920080007F (#7), has by far the smallest vertex count (518) of these puzzles. Its graph seems to contain no non-trivial loops. I suspect that when this puzzle is solved by shape, it is also solved by color.

Interestingly, the top 10 by HTM are the same but in a slightly different order.

QTM vs HTM diameter (ignoring cube orientation)

High QTM/HTM diameter

Again, several configurations achieve a the upper bound where QTM diameter is double HTM diameter. Most of these have a small diameter or seem otherwise boring. A few configurations get close and seem more interesting to me. Two that stand out are 0x1084008C238C63 (19 QTM, 10 HTM) and 0x10818086200C23 (39 QTM, 21 HTM). The former looks a lot like the cube with the largest vertex count but with a few bandaged centers.

Low QTM/HTM diameter

Many configurations achieve the lower bound where QTM and HTM diameters are equal. 0x80018620002D (discussed above) does not have any self symmetries so it is still the largest of these by diameter (17). It is also the largest by vertex count (66).

Diameter/Radius (ignoring cube orientation)

Low Diameter/Radius

There are 37 configurations where QTM radius is the same as QTM diameter. The largest of these by diameter is 0x10F4018C7C0C63 (QTM diameter = 5), which seems like it can barely scramble. Another one that jumps out at me is 0x30000080200C11 (39 QTM diameter, 30 QTM radius). Among the puzzles where QTM radius is close to QTM diameter, it has an unusually high diameter.

Comparing graphs with and without considering orientation

Change in vertex count

When we stop considering orientation, the graphs for most configurations get smaller. The factor they shrink by roughly represents how many rotated/mirrored copies of each state we expect to find in the graph.

This quotient has an lower bound of 1 - if a cube has no self-similar states then its graph will have the same number of vertices whether or not we consider orientation. The upper bound is 48, since the cube has 24 orientations and each of those has a mirror image.

Large change

Exactly one puzzle has 48x as many vertices when orientation is considered - 0x28A00000414. When considering orientation it can reach 2544 configurations, and when ignoring orientation it can only reach 53 configurations.

Achieving this bound is quite impressive. It means that for any reachable configuration of this puzzle, all 48 orientations/mirrors are reachable and distinct from one another.

A few other puzzle get quite close to a 48x reduction. The largest of these by diameter is 0x20088000000C06 (27 QTM when considering orientation, 16 QTM when ignoring it). The largest of these by vertex count is 0x28000000C14 (7344 when considering orientation, 157 when ignoring it). This cube is also notable for having the largest vertex count if we limit outself to cubes with 0 modified center pieces (9528 when considering orientation, 206 when ignoring it).

No change

Nearly 1000 puzzles have the same number of vertices whether or not orientation is considered.

The largest by diameter are 0x108430C40007A3 (seen above), then 0x500180800C3D (seen above). The largest by vertex count are 0x10840084018423 (12647) and 0x100400B4200631 (11589).

Large graphs despite large changes

Some configurations still have comparatively large graphs, even after losing a big portion of their vertices when we ignored orientation.

0x1003DE80000403 (now 18th largest) lost 3/4th of its vertices. 0x3FE0010002D (now 60th largest), lost ~7/8th of its vertices.

Change in diameter

Large change

Most of the graphs with large percentage drops in diameter end up with ~2 vertices and don’t seem too interesting to me. A few that do seem interesting are 0x10525A02800C06 (14 QTM -> 4 QTM) and 0x300000B40D85A3 (14 QTM -> 2 QTM), Both drop from 5 HTM to 1 HTM. Another notable drop is from 0x53A40280007F (84 QTM -> 34 QTM).

Small change

There are some interesting examples of graphs whose vertex count drops significantly but whose diameter does not change.

A few standouts are 0x10840000000C03 (904->127 vertices, 23 diameter QTM), 0x3F6000005AD (2304->576 vertices, 49 HTM diameter).

Bonus - other stuff that seemed interesting

Banning “normal” corners

If we limit ourselves to puzzles where every corner is bandaged to an edge, we still have 81 puzzles to look at. If we care about orientation, 0x39e00100414 has the largest diamter (36 QTM) and 0x2da00000c14 has the largest vertex count (384). If we stop caring about orientation then 0x21088300000883 has the largest diameter (30 QTM) and the largest vertex count (257).

Banning “normal” edges

If we limit ourselves to puzzles where every edge is bandaged to another piece, we still have 132 puzzles to look at. Of these, 0x21081308440862 has the largest diameter (28 QTM) whether or not we care about orientation. 0x3fe0000041c has the largest vertex count (1092) when considering orientations and 0x1003fe8000043d has the largest vertex count (321) when ignoring orientations.

Banning “normal” corners and edges

If we restrict ourselves to puzzles with no “normal” corners and no “normal” edges, there are still 12 distinct puzzles to look at. These puzzles are all extremely constrainted but some seem like they can still meaningfully scramble.

0x3FE00000C1C has the largest vertex count (156) if we care consider orientation. 0x21189308C00C46 has the largest vertex count (25) if we do not consider about orientation. It also has the largest diameter whether or not we care about orientation. 0x83FE04000631 is in third place for vertex count whether or not we care about orientation.

Banning “abnormal” centers

If we restrict ourselves to puzzles where all centers are “normal” meaning no bandaging to the core or to edges, we have 26 puzzles to look at.

0x20088000000C06 (seen above) has the largest diameter (27 QTM) of these puzzles if we care about orientation. This was was noted above for have losing a large fraction of vertices when we start caring about orientation. 0x20088000000C03 has the largest diamter (20 QTM) if we do not care about orientation.

Fun graph shapes

Here are a bunch of puzzles where the shape of their graph seemed interesting to me:

0x210B0118C00C5A has two identical looking subgraphs connected by a forced chain. I wonder if the solve will require navigating the chain frequently - or even at all.

0x1084018C7C0C30 is imilar to the above but with a much longer chain connecting the segments.

0x1080018FFC0C21 has a very unusual graph. It has a few big loops that are all connected to each other, plus so not-too-useful looking long dead ends.

0x104000B5BDB5AD has very small graph with only a few nontrivial loops. It seems like it can scramble pretty well though and would make for a challenging and highly constrained solve.

0x30018080002D has an intersting graph shape. It is sparse but hard to untangle.

Closing thoughts (again)

I’d like to re-emphasize that diameter is not a good way to predict difficulty. I’m currently fighting with 0xC00B40D85A0 which a QTM diameter of 3 and am finding it pretty difficult. That said, I think it’s difficulty is quite different from the high-diameter puzzles discussed in those post.

I’m probably done looking at the diameter data for now, but I’m certainly not done analyzing bandaged cubes. One idea I had was a web tool to help find paths between different configurations. Another idea I’m considering is building a tool that finds non-trivial loops in a puzzle’s state space; for the purpose of finding useful algorithms. If I do either of these I’ll be sure to write a blog post too.

Mix and Match Gear Cubes

Thu, 03 Nov 2022 00:00:00 +0000

Background

Oskar’s gear cube

There’s a variation on the standard 3x3x3 Rubik’s puzzle called the Gear Cube. It has the same centers, corners, and edges as a regular Rubik’s cube, but it turns differently. When you make a 180 degree turn on a face, the slice layer below it turns by 90 degrees. You cannot make 90 degree turns on faces because then the middle slice would be turned 45 degrees and would block subsequent moves.

Surprisingly, this puzzle is much easier than a Rubik’s cube. The gears dramatically reduce the number of positions that the puzzle can reach. For example, all edge on the equator of the cube are permanently stuck on the equator of the cube. According to Jaap’s puzzle page, the gear cube can reach only 41,472 different states.

Variations on Oksar’s Gear Cube

Oskar van Deventer designed several variations on the Gear Cube which increase the challenge. One was mass produced under the name Gear Cube Extreme. This puzzle replaces four of the geared edges with conventional Rubik’s cube edges, arranged along one of the middle slices of the cube. When you turn a face, its behavior depends on on the middle slice next to it. If that middle slice is composed of gear edges then the turn is like a Gear Cube. If that middle slice is composed of traditional Rubik’s Cube edges than the turn is like a Rubik’s Cube. The non-geared edges can never leave their middle layer so the solver never has to react to which turns are geared turns vs normal turns.

Another variation that Oskar designed was Even Less Gears. This puzzle replaced 8 geared edges with conventional edges. Like the Gear Cube Extreme, if there are any gears in the middle layer, turns will engage those gears. Unlike the Gear Cube Extreme, the gears can move around relative to one another. This means the solver’s strategy needs to account for the positions of the gears when executing sequences.

Puzzle Modding

I saw a reddit post where someone had modded a different style of Gear Cube so it worked like a Gear Cube Extreme. It seemed relatively straightforward so I decided to copy them, but make an Even Less Gears instead.

I used a dremel with a sanding band to remove most of the material, then hand sanded it to get a smoother finish. My initial attempt didn’t remove quite enough material which resulted in bumpy turning but I did a second round of sanding and was able to get the turning to be extremely smooth.

More modding

Playing with my modified puzzle got me wondering if there are other gear cube variations that can be made from a mix of geared and un-geared edges. I realized that if I made a copy of the gear cube extreme, I could mix and match edges between the two puzzles to make all Gear/Rubik’s cube hybrids. But what hybrids exist?

The Hybrids

As is often the case, I’m not the first one with this idea. Andreas Nortmann enumatered seven variations.

“There are no more than 7 different variants. These are:

[] The cube without gears.
[FR] The cube with a single gear.
[FL BR]
[FL FR BR]
[FL FR BR BL] “Even less Gears”
[UL UF UR UB DL DF DR DB] Gear Cube Extreme aka Anisotropic Cube
[UL UF UR UB FL FR BR BL DL DF DR DB] Gear Cube (I don’t dare to say ‘normal’)

All other variants are identical in behaviour to one of these.”

Another user on the forums actually built all of these.

Extreme vs Ultimate

Oskar’s original Gear Cube Extreme had some unstickered parts. Some people chose to add stickers to those parts and named the results the “Gear Cube Ultimate”. These stickers represent the orientation of a Rubik’s cube edge piece, independent of the orientation of the gear, and add an additional challenge.

The puzzle I’m modifying does not have these parts but I think I can partially simulate them. For example, I believe I can replace one geared edge on the Gear Cube Extreme, which will act like the Ultimate stickers without affecting the behavior of the puzzle. I need to think more about whether the other hybrids can be modified in the same way.

Bermuda Cubes

Sun, 23 May 2021 00:00:00 +0000

Background

I’ve recently been playing with a series of puzzles called the Bermuda cubes. They look and behave a like a Rubik’s cube but some centers have been replaced by triangles and others have been rotated 45 degrees. Mechanically, these new centers don’t add anything new. The pieces around them can be interchanged with regular corners and edges. From a solving perspective, these centers add a few challenges.

The unusually shaped pieces and centers make it harder for me to visualize setups.
The notation for algorithms is cumbersome which makes it harder for me to memorize them.
The triangle centers block other faces depending on their position so it’s harder to come up with broadly reusable algorithms.

One nice feature of this collection of puzzles is that they have a suggested order. Each one is named after a planet and they (mostly) get harder as the planets get further from the sun.

Now that I’ve completed the series, I wanted to write a blog post to reflect on the solving experiences and to record my solving notes for others (and maybe for my future self).

First Approach

A pretty standard technique for designing a solution is to solve one kind of piece at a time. The idea is that you can solve the solve the first piece type with ignoring the rest of the puzzle. Then you can solve the second piece type while only paying attention to the first piece type and ignoring the rest, etc. This sort of solution doesn’t require very many algorithms but does require you to be good at visualizing setups so you can get the most out of your sequences.

For this whole series, it felt most natural to me to solve centers then edges, then corners. Moving centers after anything else is solved seemed like a pain so I knew I wanted to do those first. Isolating edges without slice turns seemed like it would be painful so I chose to do those before corners.

With a bit of planning, I was able to adapt well known 3x3x3 commutators to the first few puzzles in the Bermuda cubes series. The trick was identifying which center positions were workable and then finding ways to set up to those positions. But when I started working on Mars, I found it a lot harder to adapt ideas I already knew from 3x3x3 Rubik’s cubes. That puzzle has three triangle centers, two of which are opposite each other. That means the middle one is always blocking at least one of the other triangles and that made it much trickier to access certain pieces of the puzzle.

I decided to search for sequences that depended on as few faces as possible, that way the state of the puzzle would matter as little as possible when executing them. In particular, I looked for algorithms that only depended on neighboring triangle and square faces.

My big breakthrough centered on the fact that RUR’U’ repeated 3 times has no effect on edges and is a 2,2 swap of corners. I could execute that with a square face on top and a triangle face on the right in the correct orientation. From there, I could turn this into a useful algorithm by swapping some of the pieces of the U face with the unmodified corner/edge/corner on the hypotenuse of the R face. There were a few nice ways to do that interchange and all of the ones I tried resulted in useful 3-cycles!

left: [(R U R’ U’)3, R^-1.5 U’ R^1.5]
middle: [(R U R’ U’)3, R^-1.5 U R^1.5]
right: [(R U R’ U’)3, R^-1.5 U2 R^1.5]

These cubes are tilted a bit to show the outcomes better. These should be executed with the orange face on U and the white face on R, starting with the white triangle orientated as shown.

I really like this trio of algorithms. The similarity made them easy to remember. The fact that the cube is in its normal shape most of the time meant I could use edges as clues if I ever lost my place in the middle. On top of that, they were able to easily move corners in and out of the tricky-to-reach spots on the hypotenuse of the triangular face.

For corner orientation, I also wanted to find a sequence that would work with only two turnable faces. Starting with a square face on U and a triangle face on R (orientated the same as my permutation algorithms), I realized I could execute a Sune. After a bit of fiddling, I found that three Sunes in a row had no effect on edges and swapped the corners of the square face with their diagonals. One pair’s orientation was unchanged while the other pair was twisted. That meant I could do a U2 and another triple-Sune to swap the corners back to their original positions but end up with one diagonal pair orientated differently.

left: effect after 3 Sunes
right: effect after [(R U R’ U R U2 R’)3 , U2]

You might notice that I only wrote about algorithms for corners, not ones for edges. That’s because I found the edges pretty intuitive. All these algorithms I’m writing about in this post are for using at the end of a solve when pieces are mostly where they need to be. Before that, I try to use intuition and blockbuilding as much as possible.

Oops All Triangles

At this point, I thought I’d cracked the whole series and all the was left was coming up with nice setup sequences. Then I started scrambling Saturn and realized my mistake. Even though that puzzle has two square-centered faces, neither of them is able to turn. Hilariously, the edge in between them is mechanically functional, it’s just impossible to unblock either face and actually move it. This meant all my nice ideas about triangle/square algorithms were not applicable.

I was pretty happy with my centers, edges, corners solve order and I liked the flexibility that I got from an algorithm that only needed two turnable faces; so I decided to try to find some new algorithms to use for adjacent triangular faces.

I came up with some kinda ugly ideas but I wasn’t looking forward to executing those long algorithms on an actual puzzle. Eventually I decided to give up and write a program to find some shorter sequences.

Writing a solver

In order to model the state of the puzzle, I needed to know orientation of each center. I used an enum where I named each state after the edge of the triangle that was shared with the other face:

enum Orientation : int {
  HYPOT = 0,
  LEFT_LEG = 1,
  RIGHT_LEG = 2,
};

From there, I modeled each state of the puzzle as a vector of edge locations and a vector of corner locations. This meant each move could be implemented as a permutation of those vectors.

struct Node {
  Node(const std::vector<int>& corners,
      const std::vector<int>& edges,
      const Orientation& left_center,
      const Orientation& right_center,
      const std::string& path) :
    corners_(corners),
    edges_(edges),
    left_center_(left_center),
    right_center_(right_center),
    path_(path) {}

  std::vector<int> corners_;
  std::vector<int> edges_;
  Orientation right_center_;
  Orientation left_center_;
  std::string path_;
};

One unintuitive detail is that the corners vector had one entry per sticker, not one entry per piece. That’s because I wanted to track the orientation of the corners. This wasn’t needed for edges since edges can’t change orientation with just two axes.

An example of a transformation function is as follows:

Node LhsClockwise(Node in) {
  if (in.left_center_ == Orientation::HYPOT) {
    PermuteVec(in.corners_, {
        {0,9,3,12,6},
        {1,10,4,13,7},
        {2,11,5,14,8},
      });
    in.left_center_ = Orientation::RIGHT_LEG;
  } else if (in.left_center_ == Orientation::LEFT_LEG) {
    PermuteVec(in.corners_, {
        {0,9,3,12,6},
        {1,10,4,13,7},
        {2,11,5,14,8},
      });
    in.left_center_ = Orientation::HYPOT;
  } else if (in.left_center_ == Orientation::RIGHT_LEG) {
    PermuteVec(in.corners_, {
        {0,12,9,6,3},
        {1,13,10,7,4},
        {2,14,11,8,5},
      });
    in.left_center_ = Orientation::LEFT_LEG;
  }
  PermuteVec(in.edges_, 0);
  in.path_ += "L";

  return in;
}

You might notice that I always add “L” to the path even though the number of degrees being turned isn’t always the same. To simplify notation, for triangle+triangle algorithms, I used L to mean “rotate the left triangle clockwise until the right is unblocked” and the same for “R” mutatis mutandis.

Finally, I wrote some code to breadth first search the graph, and print nodes which only modified a small number of corners. This approach worked well. By looking for states with 6 modified corner stickers, I could find pure orientation algorithms. By looking for states with 9 modified stickers, I could find permutation algorithms. I’ve included a table of about 400 algorithms that the solver found at the bottom of this post.

Aside: C++ and hashing vectors

One thing that was moderately annoying when I was writing my bfs was that I wanted to make a set of my Node struct so I could tell whether a node had been visited or not. Because it contains a vector, C++ didn’t know how to hash it so I had to write my own custom hash function. I found that a little annoying.

Second approach to writing a solver

The results from my first solver were decent but still felt awkward to me. The 2-axes approach generated algorithms that were highly reusable but were kinda long. I started to wonder if I could generate shorter ones by allowing the use of a third axis.

This meant I needed to make a few changes to how I was modeling states. First of all, I need to start modeling edges in a way that lets me see their orientation. This isn’t too bad - we can use the same trick as we did with corners and use one int for each sticker. Next, we need to model center orientation in a way that lets us see which faces are blocked. After some thought, I came up with a solution to this that felt really elegant.

We can treat each face like a regular pentagon (i.e. from a megaminx) but with some specific edges bandaged to those centers.

I updated my code to BFS using three triangular faces and this new model but the results were extremely disappointing. All the algorithms it found used just two out of three available faces! If I didn’t make any mistakes in my implementation, this means that adding a third triangular face doesn’t help at all.

Closing thoughts

If you enjoyed this and want to pick up some Bermuda cubes, you probably don’t need to get the whole set. Some, like Jupiter and Uranus feel pretty much the same with my method. I think my favorites were Mars and Neptune. Maybe start with Venus if you’re looking for something easier and maybe end with one of Jupiter/Saturn if you’re looking for something harder.

Numbering the pieces and figuring out the permutation that went with each turn was kinda tedious. I wonder if there’s a way to automate that. Also, I think there’s room for a nice library that takes the permutations of each move as input and has utilities for things like BFS written in a general way. There’s certainly some low hanging fruit when it comes to optimizing my current solver - it would be great to do that optimization on a shared library once and then benefit from it on future projects.

I think it would be fun to apply this same technique to mixes of 0 and 1 faces on the circle 3x3x3s. I think there would be lots of fun arrangements to analyze and I bet some really short algorithms would show up.

I know there is a series of Bermuda megaminxes that were also mass produced but are hard to find and expensive these days. Maybe I’ll solve a few of those in a simulator next time I’m looking for the Bermuda puzzle kind of experience.

Appendix

triangle-triangle Permutation algorithms:

(see data model above for starting position and label meanings)

Effect	Alg
(9,21,16)(10,22,17)(11,23,15)	LRLRL’RL’R’L’R’LR’
(9,18,23)(10,19,21)(11,20,22)	LRLR’LR’L’R’L’RL’R
(6,14,18)(7,12,19)(8,13,20)	LR’LRLRL’RL’R’L’R’
(6,11,20)(7,9,18)(8,10,19)	LR’LR’L’R’L’RL’RLR
(9,19,14)(10,20,12)(11,18,13)	L’RL’RLRLR’LR’L’R’
(6,18,14)(7,19,12)(8,20,13)	L’RL’R’L’R’LR’LRLR
(9,19,17)(10,20,15)(11,18,16)	L’R’L’RL’RLRLR’LR’
(9,16,21)(10,17,22)(11,15,23)	L’R’L’R’LR’LRLRL’R
(9,14,19)(10,12,20)(11,13,18)	RLRL’RL’R’L’R’LR’L
(9,17,19)(10,15,20)(11,16,18)	RL’RL’R’L’R’LR’LRL
(9,23,18)(10,21,19)(11,22,20)	R’LR’LRLRL’RL’R’L’
(6,20,11)(7,18,9)(8,19,10)	R’L’R’LR’LRLRL’RL’
(0,18,23)(1,19,21)(2,20,22)	LRLRLRL’RL’R’L’R’LRL’
(12,18,21)(13,19,22)(14,20,23)	LRLR’LRLRL’RL’R’L’RL’
(3,7,19)(4,8,20)(5,6,18)	LRL’R’LR’LRLRL’RL’RL’
(3,18,21)(4,19,22)(5,20,23)	LRL’R’L’RL’RLRLR’LRL’
(12,21,18)(13,22,19)(14,23,20)	LR’LRLR’LR’L’R’L’RL’R’L’
(3,19,7)(4,20,8)(5,18,6)	LR’LR’LR’L’R’L’RL’RLR’L’
(0,23,18)(1,21,19)(2,22,20)	LR’L’RLRLR’LR’L’R’L’R’L’
(3,21,18)(4,22,19)(5,23,20)	LR’L’RL’R’L’R’LR’LRLR’L’
(0,16,19)(1,17,20)(2,15,18)	L’RLR’LRLRL’RL’R’L’RL
(3,17,19)(4,15,20)(5,16,18)	L’RLR’L’R’L’RL’RLRLRL
(0,18,14)(1,19,12)(2,20,13)	L’RL’RL’RLRLR’LR’L’RL
(6,16,19)(7,17,20)(8,15,18)	L’RL’R’L’RL’RLRLR’LRL
(0,19,16)(1,20,17)(2,18,15)	L’R’LRLR’LR’L’R’L’RL’R’L
(0,14,18)(1,12,19)(2,13,20)	L’R’LRL’RL’R’L’R’LR’LR’L
(6,19,16)(7,20,17)(8,18,15)	L’R’L’RL’R’L’R’LR’LRLR’L
(3,19,17)(4,20,15)(5,18,16)	L’R’L’R’L’R’LR’LRLRL’R’L
(3,9,14)(4,10,12)(5,11,13)	RLRLRLR’LR’L’R’L’RLR’
(9,12,22)(10,13,23)(11,14,21)	RLRL’RLRLR’LR’L’R’LR’
(0,16,9)(1,17,10)(2,15,11)	RLR’L’RL’RLRLR’LR’LR’
(0,11,14)(1,9,12)(2,10,13)	RLR’L’R’LR’LRLRL’RLR’
(9,22,12)(10,23,13)(11,21,14)	RL’RLRL’RL’R’L’R’LR’L’R’
(0,9,16)(1,10,17)(2,11,15)	RL’RL’RL’R’L’R’LR’LRL’R’
(3,14,9)(4,12,10)(5,13,11)	RL’R’LRLRL’RL’R’L’R’L’R’
(0,14,11)(1,12,9)(2,13,10)	RL’R’LR’L’R’L’RL’RLRL’R’
(3,7,10)(4,8,11)(5,6,9)	R’LRL’RLRLR’LR’L’R’LR
(0,7,9)(1,8,10)(2,6,11)	R’LRL’R’L’R’LR’LRLRLR
(3,9,21)(4,10,22)(5,11,23)	R’LR’LR’LRLRL’RL’R’LR
(6,9,15)(7,10,16)(8,11,17)	R’LR’L’R’LR’LRLRL’RLR
(3,10,7)(4,11,8)(5,9,6)	R’L’RLRL’RL’R’L’R’LR’L’R
(3,21,9)(4,22,10)(5,23,11)	R’L’RLR’LR’L’R’L’RL’RL’R
(6,15,9)(7,16,10)(8,17,11)	R’L’R’LR’L’R’L’RL’RLRL’R
(0,9,7)(1,10,8)(2,11,6)	R’L’R’L’R’L’RL’RLRLR’L’R
(0,21,16)(1,22,17)(2,23,15)	LRLRLRLR’LR’LR’LRL’R’
(0,21,12)(1,22,13)(2,23,14)	LRLR’LRLR’L’RL’R’L’RL’R’
(3,22,12)(4,23,13)(5,21,14)	LRL’RLRL’RLR’L’R’LR’L’R’
(3,22,9)(4,23,10)(5,21,11)	LRL’RLRL’RL’R’LR’L’R’LR’
(3,10,19)(4,11,20)(5,9,18)	LRL’RLRL’R’LR’L’R’LR’L’R
(3,7,12)(4,8,13)(5,6,14)	LRL’R’LR’LR’LR’L’R’L’R’L’R’
(3,9,18)(4,10,19)(5,11,20)	LR’LRLRL’R’L’RL’R’L’R’LR
(0,18,12)(1,19,13)(2,20,14)	LR’LRLR’LRL’RL’R’L’RL’R’
(0,18,7)(1,19,8)(2,20,6)	LR’LR’LR’LRLRLRLR’L’R
(0,23,9)(1,21,10)(2,22,11)	LR’L’RLRLRLRL’RL’RL’R
(0,15,9)(1,16,10)(2,17,11)	LR’L’R’LRL’RLR’L’R’LRL’R
(0,11,18)(1,9,19)(2,10,20)	LR’L’R’LR’L’RL’RLRL’RLR’
(0,15,6)(1,16,7)(2,17,8)	LR’L’R’LR’L’R’L’RLRL’RLR
(0,9,19)(1,10,20)(2,11,18)	L’RLR’LRLR’LRL’R’L’RL’R’
(3,17,9)(4,15,10)(5,16,11)	L’RLR’L’R’L’R’L’R’LR’LR’LR’
(3,19,14)(4,20,12)(5,18,13)	L’RL’RL’RL’R’L’R’L’R’L’RLR’
(3,19,6)(4,20,7)(5,18,8)	L’RL’R’LRLR’L’RL’R’LRLR’
(0,14,6)(1,12,7)(2,13,8)	L’R’LRL’RL’RL’RLRLRLR
(3,16,6)(4,17,7)(5,15,8)	L’R’L’RLR’LRL’R’L’RLR’LR
(3,16,21)(4,17,22)(5,15,23)	L’R’L’R’L’R’L’RL’RL’RL’R’LR
(3,12,7)(4,13,8)(5,14,6)	RLRLRLRL’RL’RL’RLR’L’
(3,12,22)(4,13,23)(5,14,21)	RLRL’RLRL’R’LR’L’R’LR’L’
(0,12,21)(1,13,22)(2,14,23)	RLR’LRLR’LRL’R’L’RL’R’L’
(0,12,18)(1,13,19)(2,14,20)	RLR’LRLR’LR’L’RL’R’L’RL’
(0,19,9)(1,20,10)(2,18,11)	RLR’LRLR’L’RL’R’L’RL’R’L
(0,16,21)(1,17,22)(2,15,23)	RLR’L’RL’RL’RL’R’L’R’L’R’L’
(0,18,11)(1,19,9)(2,20,10)	RL’RLRLR’L’R’LR’L’R’L’RL
(3,9,22)(4,10,23)(5,11,21)	RL’RLRL’RLR’LR’L’R’LR’L’
(3,9,17)(4,10,15)(5,11,16)	RL’RL’RL’RLRLRLRL’R’L
(3,14,19)(4,12,20)(5,13,18)	RL’R’LRLRLRLR’LR’LR’L
(3,6,19)(4,7,20)(5,8,18)	RL’R’L’RLR’LRL’R’L’RLR’L
(3,18,9)(4,19,10)(5,20,11)	RL’R’L’RL’R’LR’LRLR’LRL’
(3,6,16)(4,7,17)(5,8,15)	RL’R’L’RL’R’L’R’LRLR’LRL
(3,19,10)(4,20,11)(5,18,9)	R’LRL’RLRL’RLR’L’R’LR’L’
(0,7,18)(1,8,19)(2,6,20)	R’LRL’R’L’R’L’R’L’RL’RL’RL’
(0,9,23)(1,10,21)(2,11,22)	R’LR’LR’LR’L’R’L’R’L’R’LRL’
(0,9,15)(1,10,16)(2,11,17)	R’LR’L’RLRL’R’LR’L’RLRL’
(3,21,16)(4,22,17)(5,23,15)	R’L’RLR’LR’LR’LRLRLRL
(0,6,15)(1,7,16)(2,8,17)	R’L’R’LRL’RLR’L’R’LRL’RL
(0,6,14)(1,7,12)(2,8,13)	R’L’R’L’R’L’R’LR’LR’LR’L’RL
(3,21,17)(4,22,15)(5,23,16)	LRLRL’R’L’R’LR’LRLRLR’L’
(3,20,10)(4,18,11)(5,19,9)	LRL’R’LR’LRLR’LRL’RL’R’L
(3,17,21)(4,15,22)(5,16,23)	LRL’R’L’R’L’RL’RLRLR’L’R’L’
(0,11,20)(1,9,18)(2,10,19)	LR’L’RL’RLR’LRLR’LR’L’RL
(3,10,20)(4,11,18)(5,9,19)	L’RLR’LR’L’RL’R’L’RL’RLR’L’
(0,23,16)(1,21,17)(2,22,15)	L’R’LRLRLR’LR’L’R’L’RLRL
(0,20,11)(1,18,9)(2,19,10)	L’R’LRL’RL’R’L’RL’R’LR’LRL’
(0,16,23)(1,17,21)(2,15,22)	L’R’L’R’LRLRL’RL’R’L’R’L’RL
(0,14,7)(1,12,8)(2,13,6)	RLRLR’L’R’L’RL’RLRLRL’R’
(0,10,19)(1,11,20)(2,9,18)	RLR’L’RL’RLRL’RLR’LR’L’R
(0,7,14)(1,8,12)(2,6,13)	RLR’L’R’L’R’LR’LRLRL’R’L’R’
(3,18,11)(4,19,9)(5,20,10)	RL’R’LR’LRL’RLRL’RL’R’LR
(0,19,10)(1,20,11)(2,18,9)	R’LRL’RL’R’LR’L’R’LR’LRL’R’
(3,14,7)(4,12,8)(5,13,6)	R’L’RLRLRL’RL’R’L’R’LRLR
(3,11,18)(4,9,19)(5,10,20)	R’L’RLR’LR’L’R’LR’L’RL’RLR’
(3,7,14)(4,8,12)(5,6,13)	R’L’R’L’RLRLR’LR’L’R’L’R’LR
(0,14,23)(1,12,21)(2,13,22)	LRLRLRL’RLRLRL’R’LR’L’R’
(3,23,13)(4,21,14)(5,22,12)	LRLRLRL’R’L’RLRLRLR’L’R’
(6,10,22)(7,11,23)(8,9,21)	LRLRL’R’LR’LR’L’R’L’RLR’LR’
(3,14,21)(4,12,22)(5,13,23)	LRLR’LRL’R’L’R’L’RL’R’L’R’L’R’
(0,22,13)(1,23,14)(2,21,12)	LRLR’L’R’L’R’L’RLRL’R’L’R’L’R’
(0,3,22)(1,4,23)(2,5,21)	LRL’RLR’LRLRL’RLR’LRL’R’
(0,5,12)(1,3,13)(2,4,14)	LRL’R’LR’L’RL’R’L’R’LR’L’RL’R’
(0,18,10)(1,19,11)(2,20,9)	LR’LRLR’L’R’L’R’L’RL’R’L’R’L’R
(12,19,15)(13,20,16)(14,18,17)	LR’LR’L’RLRLR’LR’LRL’R’L’R’
(0,20,9)(1,18,10)(2,19,11)	LR’L’R’L’R’LR’L’R’L’R’L’RLRL’R
(3,20,9)(4,18,10)(5,19,11)	L’RLRLRL’RLRLRLR’L’R’LR’
(6,18,22)(7,19,23)(8,20,21)	L’RL’RLR’L’R’L’RL’RL’R’LRLR
(3,19,11)(4,20,9)(5,18,10)	L’RL’R’L’RLRLRLR’LRLRLR’
(0,7,16)(1,8,17)(2,6,15)	L’R’LRLR’L’RL’RLR’LRLRLR
(0,8,5)(1,6,3)(2,7,4)	L’R’LRL’RLR’LRLRL’RLR’LR
(0,15,3)(1,16,4)(2,17,5)	L’R’LR’L’RL’R’L’R’LR’L’RL’R’LR
(3,15,8)(4,16,6)(5,17,7)	L’R’L’RLRLRLR’L’R’LRLRLR
(9,16,13)(10,17,14)(11,15,12)	L’R’L’R’LRL’RL’RLRLR’L’RL’R
(0,17,8)(1,15,6)(2,16,7)	L’R’L’R’L’R’LRLR’L’R’L’R’L’RLR
(3,7,17)(4,8,15)(5,6,16)	L’R’L’R’L’R’LR’L’RL’RLR’L’R’LR
(3,21,14)(4,22,12)(5,23,13)	RLRLRLR’LRLRLR’L’RL’R’L’
(0,13,22)(1,14,23)(2,12,21)	RLRLRLR’L’R’LRLRLRL’R’L’
(12,15,19)(13,16,20)(14,17,18)	RLRLR’L’RL’RL’R’L’R’LRL’RL’
(0,23,14)(1,21,12)(2,22,13)	RLRL’RLR’L’R’L’R’LR’L’R’L’R’L’
(3,13,23)(4,14,21)(5,12,22)	RLRL’R’L’R’L’R’LRLR’L’R’L’R’L’
(0,12,5)(1,13,3)(2,14,4)	RLR’LRL’RLRLR’LRL’RLR’L’
(0,22,3)(1,23,4)(2,21,5)	RLR’L’RL’R’LR’L’R’L’RL’R’LR’L’
(3,9,20)(4,10,18)(5,11,19)	RL’RLRL’R’L’R’L’R’LR’L’R’L’R’L
(6,22,10)(7,23,11)(8,21,9)	RL’RL’R’LRLRL’RL’RLR’L’R’L’
(3,11,19)(4,9,20)(5,10,18)	RL’R’L’R’L’RL’R’L’R’L’R’LRLR’L
(0,10,18)(1,11,19)(2,9,20)	R’LRLRLR’LRLRLRL’R’L’RL’
(9,13,16)(10,14,17)(11,12,15)	R’LR’LRL’R’L’R’LR’LR’L’RLRL
(0,9,20)(1,10,18)(2,11,19)	R’LR’L’R’LRLRLRL’RLRLRL’
(3,17,7)(4,15,8)(5,16,6)	R’L’RLRL’R’LR’LRL’RLRLRL
(0,3,15)(1,4,16)(2,5,17)	R’L’RLR’LRL’RLRLR’LRL’RL
(0,5,8)(1,3,6)(2,4,7)	R’L’RL’R’LR’L’R’L’RL’R’LR’L’RL
(0,8,17)(1,6,15)(2,7,16)	R’L’R’LRLRLRL’R’L’RLRLRL
(6,22,18)(7,23,19)(8,21,20)	R’L’R’L’RLR’LR’LRLRL’R’LR’L
(3,8,15)(4,6,16)(5,7,17)	R’L’R’L’R’L’RLRL’R’L’R’L’R’LRL
(0,16,7)(1,17,8)(2,15,6)	R’L’R’L’R’L’RL’R’LR’LRL’R’L’RL
(12,21,17)(13,22,15)(14,23,16)	LRLRL’RL’RLRLR’LR’L’RL’R’L’
(6,12,16)(7,13,17)(8,14,15)	LRLRL’R’LR’LRLRL’RL’RL’R’L’
(12,17,21)(13,15,22)(14,16,23)	LRLR’LRL’RL’R’L’R’LR’LR’L’R’L’
(6,16,12)(7,17,13)(8,15,14)	LRLR’LR’LR’L’R’L’RL’RLR’L’R’L’
(3,22,8)(4,23,6)(5,21,7)	LRL’RL’R’LR’LRLRL’RL’RLR’L’
(3,8,22)(4,6,23)(5,7,21)	LRL’R’LR’LR’L’R’L’RL’RLR’LR’L’
(6,14,17)(7,12,15)(8,13,16)	LR’LRLRLRL’RL’R’L’R’LRL’RL’
(3,11,20)(4,9,18)(5,10,19)	LR’LRLR’L’R’L’R’L’RLRL’R’L’R’L
(6,17,14)(7,15,12)(8,16,13)	LR’LR’L’RLRLR’LR’L’R’L’R’L’RL’
(0,17,20)(1,15,18)(2,16,19)	LR’L’RL’RL’RLRLR’LR’L’RLRL’
(0,3,20)(1,4,18)(2,5,19)	LR’L’RL’R’L’RL’RLRLR’LRLRL’
(0,20,17)(1,18,15)(2,19,16)	LR’L’R’LRL’RL’R’L’R’LR’LR’LRL’
(0,20,10)(1,18,11)(2,19,9)	LR’L’R’L’RLRL’R’L’R’L’R’LRLR’L
(0,20,3)(1,18,4)(2,19,5)	LR’L’R’L’RL’R’L’R’LR’LRLR’LRL’
(3,20,11)(4,18,9)(5,19,10)	L’RLRLR’L’R’LRLRLRL’R’L’RL’
(3,20,23)(4,18,21)(5,19,22)	L’RLRL’R’LR’LRLRL’RL’RL’R’L
(3,23,20)(4,21,18)(5,22,19)	L’RLR’LR’LR’L’R’L’RL’RLR’L’R’L
(6,14,22)(7,12,23)(8,13,21)	L’RL’RLR’L’R’L’RL’RLRLRLR’L
(0,10,20)(1,11,18)(2,9,19)	L’RL’R’L’RLRLRLR’L’R’LRLRL’
(6,22,14)(7,23,12)(8,21,13)	L’RL’R’L’R’L’R’LR’LRLRL’R’LR’L
(0,13,15)(1,14,16)(2,12,17)	L’R’LRL’RL’RLRLR’LR’L’RL’RL
(0,15,13)(1,16,14)(2,17,12)	L’R’LR’LRL’RL’R’L’R’LR’LR’L’RL
(6,12,21)(7,13,22)(8,14,23)	L’R’L’RL’RL’RLRLR’LR’L’RLRL
(6,23,16)(7,21,17)(8,22,15)	L’R’L’RL’R’LR’LRLRL’RL’RLRL
(6,21,12)(7,22,13)(8,23,14)	L’R’L’R’LRL’RL’R’L’R’LR’LR’LRL
(6,16,23)(7,17,21)(8,15,22)	L’R’L’R’LR’LR’L’R’L’RL’RLR’LRL
(6,23,13)(7,21,14)(8,22,12)	RLRLR’LR’LRLRL’RL’R’LR’L’R’
(6,15,21)(7,16,22)(8,17,23)	RLRLR’L’RL’RLRLR’LR’LR’L’R’
(6,13,23)(7,14,21)(8,12,22)	RLRL’RLR’LR’L’R’L’RL’RL’R’L’R’
(6,21,15)(7,22,16)(8,23,17)	RLRL’RL’RL’R’L’R’LR’LRL’R’L’R’
(0,12,17)(1,13,15)(2,14,16)	RLR’LR’L’RL’RLRLR’LR’LRL’R’
(0,17,12)(1,15,13)(2,16,14)	RLR’L’RL’RL’R’L’R’LR’LRL’RL’R’
(6,17,22)(7,15,23)(8,16,21)	RL’RLRLRLR’LR’L’R’L’RLR’LR’
(6,22,17)(7,23,15)(8,21,16)	RL’RL’R’LRLRL’RL’R’L’R’L’R’LR’
(3,8,11)(4,6,9)(5,7,10)	RL’R’LR’LR’LRLRL’RL’R’LRLR’
(0,10,5)(1,11,3)(2,9,4)	RL’R’LR’L’R’LR’LRLRL’RLRLR’
(3,11,8)(4,9,6)(5,10,7)	RL’R’L’RLR’LR’L’R’L’RL’RL’RLR’
(0,5,10)(1,3,11)(2,4,9)	RL’R’L’R’LR’L’R’L’RL’RLRL’RLR’
(0,10,13)(1,11,14)(2,9,12)	R’LRLR’L’RL’RLRLR’LR’LR’L’R
(0,13,10)(1,14,11)(2,12,9)	R’LRL’RL’RL’R’L’R’LR’LRL’R’L’R
(12,15,23)(13,16,21)(14,17,22)	R’LR’LRL’R’L’R’LR’LRLRLRL’R
(12,23,15)(13,21,16)(14,22,17)	R’LR’L’R’L’R’L’RL’RLRLR’L’RL’R
(3,23,6)(4,21,7)(5,22,8)	R’L’RLR’LR’LRLRL’RL’R’LR’LR
(3,6,23)(4,7,21)(5,8,22)	R’L’RL’RLR’LR’L’R’L’RL’RL’R’LR
(12,16,22)(13,17,23)(14,15,21)	R’L’R’LR’LR’LRLRL’RL’R’LRLR
(6,15,13)(7,16,14)(8,17,12)	R’L’R’LR’L’RL’RLRLR’LR’LRLR
(12,22,16)(13,23,17)(14,21,15)	R’L’R’L’RLR’LR’L’R’L’RL’RL’RLR
(6,13,15)(7,14,16)(8,12,17)	R’L’R’L’RL’RL’R’L’R’LR’LRL’RLR
(0,11,23)(1,9,21)(2,10,22)	LRLRLRL’RLR’LRLRLRL’RLR’
(3,12,18)(4,13,19)(5,14,20)	LRLR’LRLRLRL’RL’R’L’RL’RL’R
(3,9,23)(4,10,21)(5,11,22)	LRL’RLR’L’R’LRLR’LR’LRLRLR’
(3,23,9)(4,21,10)(5,22,11)	LRL’RL’RLR’L’R’LR’LR’L’RL’RLR’
(3,18,10)(4,19,11)(5,20,9)	LRL’R’LR’L’RL’RLR’LR’L’RL’R’LR
(3,10,18)(4,11,19)(5,9,20)	LRL’R’LR’L’R’L’R’L’R’LRLR’L’R’LR’
(0,11,19)(1,9,20)(2,10,18)	LR’LRLR’L’R’LRLRLRLR’LRL’R’
(15,20,21)(16,18,22)(17,19,23)	LR’LRLR’L’R’LRL’R’L’RL’R’LRL’R
(6,10,12)(7,11,13)(8,9,14)	LR’LRL’R’LR’L’R’LRL’R’L’RLRL’R
(3,10,16)(4,11,17)(5,9,15)	LR’LR’LR’L’R’LR’LRLRLRL’RLR
(0,18,13)(1,19,14)(2,20,12)	LR’L’RL’RLR’LR’LRLR’L’RL’RL’R’
(3,14,18)(4,12,19)(5,13,20)	LR’L’RL’R’L’R’L’R’LR’L’RL’R’L’R’L’R’
(0,13,18)(1,14,19)(2,12,20)	LR’L’R’L’R’LR’LR’L’R’LRLR’L’RL’R’
(3,8,19)(4,6,20)(5,7,18)	L’RLRLRLRL’R’L’RLRL’RL’R’LR
(0,7,19)(1,8,20)(2,6,18)	L’RLR’LRLRLRL’RLR’LRLRLR
(3,19,8)(4,20,6)(5,18,7)	L’RLR’LR’L’RL’RLR’LRL’R’L’R’LR
(0,11,21)(1,9,22)(2,10,23)	L’RL’RL’RLRL’RL’R’L’R’L’R’LR’L’R’
(6,12,11)(7,13,9)(8,14,10)	L’RL’R’LRL’RLRL’R’LRLR’L’R’LR’
(15,21,19)(16,22,20)(17,23,18)	L’RL’R’L’RLRL’R’LRLR’LRL’R’LR’
(0,17,9)(1,15,10)(2,16,11)	L’R’LRLRL’R’LR’L’RL’RLR’LR’L’R
(0,19,11)(1,20,9)(2,18,10)	L’R’LRL’RLR’LR’L’RL’RLR’LRL’R’
(0,9,17)(1,10,15)(2,11,16)	L’R’LRL’RL’R’L’RLRL’R’L’R’L’R’L’R
(0,6,19)(1,7,20)(2,8,18)	L’R’L’RL’R’L’R’L’R’LR’LRLR’LR’LR’
(3,10,17)(4,11,15)(5,9,16)	L’R’L’R’L’R’LR’L’RL’R’L’R’L’R’LR’L’R
(3,18,14)(4,19,12)(5,20,13)	RLRLRLR’LRL’RLRLRLR’LRL’
(0,21,11)(1,22,9)(2,23,10)	RLRL’RLRLRLR’LR’L’R’LR’LR’L
(6,11,12)(7,9,13)(8,10,14)	RL’RLRL’R’L’RLR’L’R’LR’L’RLR’L
(15,19,21)(16,20,22)(17,18,23)	RL’RLR’L’RL’R’L’RLR’L’R’LRLR’L
(0,19,6)(1,20,7)(2,18,8)	RL’RL’RL’R’L’RL’RLRLRLR’LRL
(0,23,11)(1,21,9)(2,22,10)	RL’R’LR’L’R’L’R’L’RL’R’LR’L’R’L’R’L’
(3,17,10)(4,15,11)(5,16,9)	R’LRL’RLRLRLR’LRL’RLRLRL
(3,18,12)(4,19,13)(5,20,14)	R’LR’LR’LRLR’LR’L’R’L’R’L’RL’R’L’
(15,21,20)(16,22,18)(17,23,19)	R’LR’L’RLR’LRLR’L’RLRL’R’L’RL’
(6,12,10)(7,13,11)(8,14,9)	R’LR’L’R’LRLR’L’RLRL’RLR’L’RL’
(3,16,10)(4,17,11)(5,15,9)	R’L’R’LR’L’R’L’R’L’RL’RLRL’RL’RL’
(0,19,7)(1,20,8)(2,18,6)	R’L’R’L’R’L’RL’R’LR’L’R’L’R’L’RL’R’L
(0,8,16)(1,6,17)(2,7,15)	LRLRLRLRLR’LR’L’R’L’RLR’L’R’L’
(3,21,10)(4,22,11)(5,23,9)	LRLRLRLR’L’R’LR’L’R’L’RLRLR’L’
(0,7,23)(1,8,21)(2,6,22)	LRLRLRL’RL’RLR’L’R’L’RL’RL’RL’
(3,21,11)(4,22,9)(5,23,10)	LRLRLRL’R’L’R’L’R’LRLRLR’L’R’L
(12,18,17)(13,19,15)(14,20,16)	LRLRL’RL’RLRLR’L’RL’RL’R’L’RL’
(0,16,8)(1,17,6)(2,15,7)	LRLRL’R’LRLRL’RL’R’L’R’L’R’L’R’L’
(3,18,17)(4,19,15)(5,20,16)	LRLRL’R’L’R’LR’LR’L’RLRLR’LRL’
(3,12,17)(4,13,15)(5,14,16)	LRLR’LRL’RL’RL’RLRLRLRLR’L’
(3,21,13)(4,22,14)(5,23,12)	LRLR’LR’LRL’RLRL’RL’R’LR’LR’L’
(6,21,13)(7,22,14)(8,23,12)	LRLR’LR’LR’LRLRL’RL’R’LRL’R’L’
(9,22,14)(10,23,12)(11,21,13)	LRLR’LR’L’R’LR’LRLRL’RLRL’R’L’
(6,22,11)(7,23,9)(8,21,10)	LRLR’LR’L’R’L’RLR’LR’LRLRL’RL’
(3,12,6)(4,13,7)(5,14,8)	LRLR’L’RLR’LRL’R’L’RLR’LRLR’L’
(6,13,21)(7,14,22)(8,12,23)	LRLR’L’RLR’LR’L’R’L’RL’RL’RL’R’L’
(3,22,13)(4,23,14)(5,21,12)	LRLR’L’RL’R’LR’LRLR’LRL’RLR’L’
(9,14,22)(10,12,23)(11,13,21)	LRLR’L’R’LR’L’R’L’RL’RLRL’RL’R’L’
(6,21,14)(7,22,12)(8,23,13)	LRL’RLRL’RLRLR’LR’L’R’LR’LR’L’
(9,20,22)(10,18,23)(11,19,21)	LRL’RLRL’RL’RL’R’L’R’LR’L’R’L’R’L
(6,23,11)(7,21,9)(8,22,10)	LRL’RLRL’R’L’R’LR’LRLRLR’LR’L’
(6,14,21)(7,12,22)(8,13,23)	LRL’RL’RLRL’RL’R’L’R’LR’L’R’LR’L’
(3,13,21)(4,14,22)(5,12,23)	LRL’RL’RLR’LR’L’R’LR’L’RL’RL’R’L’
(3,10,21)(4,11,22)(5,9,23)	LRL’RL’RLR’L’R’LRL’RLR’L’R’L’R’L’
(6,11,23)(7,9,21)(8,10,22)	LRL’RL’R’L’R’L’RL’RLRLR’L’R’LR’L’
(3,15,19)(4,16,20)(5,17,18)	LRL’R’LR’LR’L’RLRLR’LR’LRL’RL’
(3,13,22)(4,14,23)(5,12,21)	LRL’R’LR’L’RL’R’L’RL’RLR’LRL’R’L’
(3,6,12)(4,7,13)(5,8,14)	LRL’R’L’RL’R’LRLR’L’RL’R’LRL’R’L’
(3,17,12)(4,15,13)(5,16,14)	LRL’R’L’R’L’R’L’R’LR’LR’LR’L’RL’R’L’
(6,12,23)(7,13,21)(8,14,22)	LR’LRLR’LR’LRLRL’RL’R’LR’L’RL’
(12,17,18)(13,15,19)(14,16,20)	LR’LRLR’LR’LRL’R’L’R’LR’LR’L’R’L’
(3,12,21)(4,13,22)(5,14,23)	LR’LRLR’LR’LR’LRLRLRLR’LRL’
(0,12,20)(1,13,18)(2,14,19)	LR’LRLR’LR’L’R’LR’L’RL’RLRLRL’
(6,23,12)(7,21,13)(8,22,14)	LR’LRL’RLR’LR’L’R’L’RL’RL’R’L’RL’
(0,14,8)(1,12,6)(2,13,7)	LR’LRL’R’L’RL’RLR’LRLR’LR’LRL’
(0,23,7)(1,21,8)(2,22,6)	LR’LR’LR’LRLRL’R’LR’LR’L’R’L’R’L’
(3,22,16)(4,23,17)(5,21,15)	LR’LR’LR’LR’LRLRL’RL’R’LRL’RL’
(3,15,7)(4,16,8)(5,17,6)	LR’LR’LR’L’RL’RLRLR’LR’LRL’RL’
(3,16,22)(4,17,23)(5,15,21)	LR’LR’L’RLR’LR’L’R’L’RL’RL’RL’RL’
(3,19,15)(4,20,16)(5,18,17)	LR’LR’L’RL’RL’R’L’R’LRL’RL’RLR’L’
(3,7,15)(4,8,16)(5,6,17)	LR’LR’L’RL’RL’R’L’R’LR’LRL’RL’RL’
(6,11,22)(7,9,23)(8,10,21)	LR’LR’L’R’L’RL’RL’R’LRLRL’RL’R’L’
(9,14,16)(10,12,17)(11,13,15)	LR’L’RLRL’R’LR’L’RL’R’L’R’L’RL’RL
(0,8,14)(1,6,12)(2,7,13)	LR’L’RL’RL’R’L’RL’R’LR’LRLR’L’RL’
(3,17,18)(4,15,19)(5,16,20)	LR’L’RL’R’L’R’LRL’RL’RLRLR’L’R’L’
(3,21,12)(4,22,13)(5,23,14)	LR’L’RL’R’L’R’L’R’L’RL’RL’RL’R’L’RL’
(12,18,15)(13,19,16)(14,20,17)	LR’L’R’LRLRLR’LR’L’R’L’RLRLRL’
(0,10,16)(1,11,17)(2,9,15)	LR’L’R’LRLRLR’L’R’L’R’L’RLRLRL
(9,20,15)(10,18,16)(11,19,17)	LR’L’R’LR’L’R’LR’LRLRL’RLRLRL’
(6,14,15)(7,12,16)(8,13,17)	LR’L’R’LR’L’R’L’R’L’RL’RLRL’RL’RL
(12,15,18)(13,16,19)(14,17,20)	LR’L’R’L’R’LRLRL’RL’R’L’R’L’RLRL’
(0,20,12)(1,18,13)(2,19,14)	LR’L’R’L’R’LR’LRL’RLRL’RL’R’L’RL’
(9,15,20)(10,16,18)(11,17,19)	LR’L’R’L’R’LR’L’R’L’RL’RLRL’RLRL’
(9,22,20)(10,23,18)(11,21,19)	L’RLRLRL’RLRLR’LR’LR’L’R’LR’L’
(3,20,6)(4,18,7)(5,19,8)	L’RLRLRL’RL’R’LR’L’R’LR’LRLR’L
(6,22,19)(7,23,20)(8,21,18)	L’RLRLRL’R’L’R’LR’LRLRLR’L’R’L
(3,11,21)(4,9,22)(5,10,23)	L’RLRL’R’L’R’L’RLRLRLR’L’R’L’R’L’
(6,19,22)(7,20,23)(8,18,21)	L’RLRL’R’L’R’L’RL’RLRLR’L’R’L’R’L
(0,16,6)(1,17,7)(2,15,8)	L’RLR’LRLRLRLR’LR’LR’LRLR’L
(0,23,19)(1,21,20)(2,22,18)	L’RLR’LRLRL’R’LR’LR’L’R’L’RLRL
(0,12,6)(1,13,7)(2,14,8)	L’RLR’LRLR’LRLR’L’RL’R’L’RLR’L
(3,13,7)(4,14,8)(5,12,6)	L’RLR’LR’LRLR’LRL’RL’R’L’RLR’L
(9,17,14)(10,15,12)(11,16,13)	L’RL’RLRLR’LR’LRL’R’L’R’LR’LRL
(0,14,22)(1,12,23)(2,13,21)	L’RL’RLR’LR’LRLRL’RL’R’LR’LR’L
(0,18,22)(1,19,23)(2,20,21)	L’RL’RLR’LR’LRLRL’R’LR’LR’L’RL
(0,21,15)(1,22,16)(2,23,17)	L’RL’RLR’L’RL’RLRLR’LR’LR’LR’L
(0,22,14)(1,23,12)(2,21,13)	L’RL’RL’RLR’LR’L’R’L’RL’RL’R’LR’L
(0,15,21)(1,16,22)(2,17,23)	L’RL’RL’RL’RL’R’L’R’LR’LRL’R’LR’L
(3,17,14)(4,15,12)(5,16,13)	L’RL’RL’RL’R’L’R’LRL’RL’RLRLRL
(0,6,12)(1,7,13)(2,8,14)	L’RL’R’LRLR’LRL’R’L’RL’R’L’RL’R’L
(3,7,13)(4,8,14)(5,6,12)	L’RL’R’LRLR’LR’L’RL’R’L’RL’RL’R’L
(6,12,17)(7,13,15)(8,14,16)	L’RL’R’LR’L’RL’RLRLR’LR’LRLR’L
(3,6,20)(4,7,18)(5,8,19)	L’RL’R’L’RL’RLRL’RLR’LR’L’R’L’R’L
(0,6,16)(1,7,17)(2,8,15)	L’RL’R’L’RL’RL’RL’R’L’R’L’R’L’RL’R’L
(6,23,19)(7,21,20)(8,22,18)	L’RL’R’L’RL’RL’R’LRLRL’RL’RLRL
(6,17,12)(7,15,13)(8,16,14)	L’RL’R’L’RL’RL’R’L’R’LR’LRL’RLR’L
(0,23,6)(1,21,7)(2,22,8)	L’R’LRLRLRLRL’RL’RL’RLR’LRL
(0,11,16)(1,9,17)(2,10,15)	L’R’LRLRL’RLRL’R’LR’L’R’LR’LRL
(0,8,15)(1,6,16)(2,7,17)	L’R’LRL’RLR’LRLR’LR’L’RL’R’LRL
(0,22,18)(1,23,19)(2,21,20)	L’R’LRL’RL’RLR’L’R’L’RL’RL’R’LR’L
(9,16,14)(10,17,12)(11,15,13)	L’R’LR’LRLRLR’LRL’RLR’L’R’LRL’
(6,15,14)(7,16,12)(8,17,13)	L’R’LR’LR’L’R’LR’LRLRLRL’RLRL’
(6,17,11)(7,15,9)(8,16,10)	L’R’L’RLRL’RLRLR’LR’L’R’LR’LRL
(0,15,8)(1,16,6)(2,17,7)	L’R’L’RLR’LRL’RL’R’L’RL’R’LR’L’RL
(6,17,13)(7,15,14)(8,16,12)	L’R’L’RLR’L’RL’RLRLR’LR’LR’LRL
(9,14,17)(10,12,15)(11,13,16)	L’R’L’RL’RLRLR’L’RL’RL’R’L’R’LR’L
(0,16,11)(1,17,9)(2,15,10)	L’R’L’RL’RLRL’RLR’L’R’LR’L’R’L’RL
(6,11,17)(7,9,15)(8,10,16)	L’R’L’RL’RLRL’RL’R’L’R’LR’L’R’LRL
(6,13,17)(7,14,15)(8,12,16)	L’R’L’RL’RL’RL’R’L’R’LR’LRL’R’LRL
(0,6,23)(1,7,21)(2,8,22)	L’R’L’RL’R’LR’LR’LR’L’R’L’R’L’R’L’RL
(0,19,23)(1,20,21)(2,18,22)	L’R’L’R’LRLRL’RL’RLR’L’R’L’RL’R’L
(6,19,23)(7,20,21)(8,18,22)	L’R’L’R’LR’LR’L’R’L’RLR’LR’LRLR’L
(0,16,10)(1,17,11)(2,15,9)	L’R’L’R’L’R’LRLRLRL’R’L’R’L’RLRL’
(3,14,17)(4,12,15)(5,13,16)	L’R’L’R’L’R’LR’LR’L’RLRLR’LR’LR’L
(0,14,19)(1,12,20)(2,13,18)	RLRLRLRL’R’L’RL’R’L’R’LRLRL’R’
(0,14,20)(1,12,18)(2,13,19)	RLRLRLR’L’R’L’R’L’RLRLRL’R’L’R
(6,23,10)(7,21,11)(8,22,9)	RLRLR’LR’LRLRL’R’LR’LR’L’R’LR’
(0,11,7)(1,9,8)(2,10,6)	RLRLR’L’R’L’RL’RL’R’LRLRL’RLR’
(0,21,7)(1,22,8)(2,23,6)	RLRL’RLR’LR’LR’LRLRLRLRL’R’
(12,23,16)(13,21,17)(14,22,15)	RLRL’RL’RL’RLRLR’LR’L’RLR’L’R’
(12,23,18)(13,21,19)(14,22,20)	RLRL’RL’R’L’RL’RLRLR’LRLR’L’R’
(12,20,15)(13,18,16)(14,19,17)	RLRL’RL’R’L’R’LRL’RL’RLRLR’LR’
(12,16,23)(13,17,21)(14,15,22)	RLRL’R’LRL’RL’R’L’R’LR’LR’LR’L’R’
(0,12,22)(1,13,23)(2,14,21)	RLRL’R’LR’L’RL’RLRL’RLR’LRL’R’
(12,18,23)(13,19,21)(14,20,22)	RLRL’R’L’RL’R’L’R’LR’LRLR’LR’L’R’
(12,21,16)(13,22,17)(14,23,15)	RLR’LRLR’LRLRL’RL’R’L’RL’RL’R’
(9,14,20)(10,12,18)(11,13,19)	RLR’LRLR’LR’LR’L’R’L’RL’R’L’R’L’R
(12,19,17)(13,20,15)(14,18,16)	RLR’LRLR’L’R’L’RL’RLRLRL’RL’R’
(12,16,21)(13,17,22)(14,15,23)	RLR’LR’LRLR’LR’L’R’L’RL’R’L’RL’R’
(0,19,14)(1,20,12)(2,18,13)	RLR’LR’LRL’R’L’RLR’LRL’R’L’R’L’R’
(12,17,19)(13,15,20)(14,16,18)	RLR’LR’L’R’L’R’LR’LRLRL’R’L’RL’R’
(0,8,9)(1,6,10)(2,7,11)	RLR’L’RL’RL’R’LRLRL’RL’RLR’LR’
(0,22,12)(1,23,13)(2,21,14)	RLR’L’RL’R’LR’L’R’LR’LRL’RLR’L’R’
(0,7,21)(1,8,22)(2,6,23)	RLR’L’R’L’R’L’R’L’RL’RL’RL’R’LR’L’R’
(12,17,23)(13,15,21)(14,16,22)	RL’RLRL’RL’RLRLR’LR’L’RL’R’LR’
(6,10,23)(7,11,21)(8,9,22)	RL’RLRL’RL’RLR’L’R’L’RL’RL’R’L’R’
(0,21,14)(1,22,12)(2,23,13)	RL’RLRL’RL’RL’RLRLRLRL’RLR’
(3,22,11)(4,23,9)(5,21,10)	RL’RLRL’RL’R’L’RL’R’LR’LRLRLR’
(12,23,17)(13,21,15)(14,22,16)	RL’RLR’LRL’RL’R’L’R’LR’LR’L’R’LR’
(3,21,15)(4,22,16)(5,23,17)	RL’RLR’L’R’LR’LRL’RLRL’RL’RLR’
(0,9,8)(1,10,6)(2,11,7)	RL’RL’R’LR’LR’L’R’L’RLR’LR’LRL’R’
(12,15,20)(13,16,18)(14,17,19)	RL’RL’R’L’R’LR’LR’L’RLRLR’LR’L’R’
(6,18,23)(7,19,21)(8,20,22)	RL’R’LRLR’L’RL’R’LR’L’R’L’R’LR’LR
(3,15,21)(4,16,22)(5,17,23)	RL’R’LR’LR’L’R’LR’L’RL’RLRL’R’LR’
(0,7,11)(1,8,9)(2,6,10)	RL’R’LR’L’R’L’RLR’LR’LRLRL’R’L’R’
(0,14,21)(1,12,22)(2,13,23)	RL’R’LR’L’R’L’R’L’R’LR’LR’LR’L’R’LR’
(6,22,9)(7,23,10)(8,21,11)	RL’R’L’RLRLRL’RL’R’L’R’LRLRLR’
(3,20,7)(4,18,8)(5,19,6)	RL’R’L’RLRLRL’R’L’R’L’R’LRLRLR
(6,19,11)(7,20,9)(8,18,10)	RL’R’L’RL’R’L’RL’RLRLR’LRLRLR’
(6,16,21)(7,17,22)(8,15,23)	RL’R’L’RL’R’L’R’L’R’LR’LRLR’LR’LR
(6,9,22)(7,10,23)(8,11,21)	RL’R’L’R’L’RLRLR’LR’L’R’L’R’LRLR’
(3,11,22)(4,9,23)(5,10,21)	RL’R’L’R’L’RL’RLR’LRLR’LR’L’R’LR’
(6,11,19)(7,9,20)(8,10,18)	RL’R’L’R’L’RL’R’L’R’LR’LRLR’LRLR’
(9,20,14)(10,18,12)(11,19,13)	R’LRLRLR’LRLRL’RL’RL’R’L’RL’R’
(0,10,15)(1,11,16)(2,9,17)	R’LRLRLR’LR’L’RL’R’L’RL’RLRL’R
(9,15,12)(10,16,13)(11,17,14)	R’LRLRLR’L’R’L’RL’RLRLRL’R’L’R
(0,20,14)(1,18,12)(2,19,13)	R’LRLR’L’R’L’R’LRLRLRL’R’L’R’L’R’
(9,12,15)(10,13,16)(11,14,17)	R’LRLR’L’R’L’R’LR’LRLRL’R’L’R’L’R
(3,7,16)(4,8,17)(5,6,15)	R’LRL’RLRLRLRL’RL’RL’RLRL’R
(3,14,10)(4,12,11)(5,13,9)	R’LRL’RLRLR’L’RL’RL’R’L’R’LRLR
(0,22,16)(1,23,17)(2,21,15)	R’LRL’RL’RLRL’RLR’LR’L’R’LRL’R
(6,22,20)(7,23,18)(8,21,19)	R’LR’LRLRL’RL’RLR’L’R’L’RL’RLR
(3,9,13)(4,10,14)(5,11,12)	R’LR’LRL’RL’RLRLR’L’RL’RL’R’LR
(0,16,22)(1,17,23)(2,15,21)	R’LR’L’RLRL’RL’R’LR’L’R’LR’LR’L’R
(6,17,23)(7,15,21)(8,16,22)	R’LR’L’RL’R’LR’LRLRL’RL’RLRL’R
(0,15,10)(1,16,11)(2,17,9)	R’LR’L’R’LR’LRLR’LRL’RL’R’L’R’L’R
(3,16,7)(4,17,8)(5,15,6)	R’LR’L’R’LR’LR’LR’L’R’L’R’L’R’LR’L’R
(9,15,13)(10,16,14)(11,17,12)	R’LR’L’R’LR’LR’L’RLRLR’LR’LRLR
(6,23,17)(7,21,15)(8,22,16)	R’LR’L’R’LR’LR’L’R’L’RL’RLR’LRL’R
(3,14,16)(4,12,17)(5,13,15)	R’L’RLRLRLRLR’LR’LR’LRL’RLR
(3,18,7)(4,19,8)(5,20,6)	R’L’RLRLR’LRLR’L’RL’R’L’RL’RLR
(3,15,6)(4,16,7)(5,17,8)	R’L’RLR’LRL’RLRL’RL’R’LR’L’RLR
(3,13,9)(4,14,10)(5,12,11)	R’L’RLR’LR’LRL’R’L’R’LR’LR’L’RL’R
(6,23,18)(7,21,19)(8,22,20)	R’L’RL’RLRLRL’RLR’LRL’R’L’RLR’
(6,21,16)(7,22,17)(8,23,15)	R’L’RL’RL’R’L’RL’RLRLRLR’LRLR’
(6,19,17)(7,20,15)(8,18,16)	R’L’R’LRLR’LRLRL’RL’R’L’RL’RLR
(3,6,15)(4,7,16)(5,8,17)	R’L’R’LRL’RLR’LR’L’R’LR’L’RL’R’LR
(6,21,17)(7,22,15)(8,23,16)	R’L’R’LRL’R’LR’LRLRL’RL’RL’RLR
(6,20,22)(7,18,23)(8,19,21)	R’L’R’LR’LRLRL’R’LR’LR’L’R’L’RL’R
(3,7,18)(4,8,19)(5,6,20)	R’L’R’LR’LRLR’LRL’R’L’RL’R’L’R’LR
(6,17,19)(7,15,20)(8,16,18)	R’L’R’LR’LRLR’LR’L’R’L’RL’R’L’RLR
(6,17,21)(7,15,22)(8,16,23)	R’L’R’LR’LR’LR’L’R’L’RL’RLR’L’RLR
(3,16,14)(4,17,12)(5,15,13)	R’L’R’LR’L’RL’RL’RL’R’L’R’L’R’L’R’LR
(3,10,14)(4,11,12)(5,9,13)	R’L’R’L’RLRLR’LR’LRL’R’L’R’LR’L’R
(9,13,15)(10,14,16)(11,12,17)	R’L’R’L’RL’RL’R’L’R’LRL’RL’RLRL’R
(3,7,20)(4,8,18)(5,6,19)	R’L’R’L’R’L’RLRLRLR’L’R’L’R’LRLR’
(0,21,8)(1,22,6)(2,23,7)	LRLRL’R’LRLRL’RL’RLR’LR’LRL’R’
(3,10,22)(4,11,23)(5,9,21)	LRLRL’R’L’RLRL’R’LR’L’R’LR’LR’LR’
(0,3,10)(1,4,11)(2,5,9)	LRL’RLRL’R’LR’LR’LR’L’R’LR’LRL’R’
(0,5,19)(1,3,20)(2,4,18)	LRL’R’LR’LRLR’LR’LR’LRL’R’L’RL’R’
(3,15,12)(4,16,13)(5,17,14)	LRL’R’LR’LR’L’RL’RL’R’L’R’LRL’R’L’R’
(3,10,13)(4,11,14)(5,9,12)	LR’LRLR’LRL’RLRLRL’RL’R’LR’L’R
(9,12,20)(10,13,18)(11,14,19)	LR’LRLR’LR’L’R’LR’LR’L’R’L’RLRL’R
(9,17,20)(10,15,18)(11,16,19)	LR’LRLR’L’R’L’RL’RL’R’L’RL’RLRL’R
(0,12,19)(1,13,20)(2,14,18)	LR’LR’LR’LRLR’LRL’R’L’RLRL’R’L’R’
(3,15,18)(4,16,19)(5,17,20)	LR’L’RL’R’LR’LRLRLR’LRL’RLRL’R
(0,15,12)(1,16,13)(2,17,14)	LR’L’R’LRLRLR’LRL’RLRLRL’R’L’R
(0,11,3)(1,9,4)(2,10,5)	LR’L’R’LR’L’RL’RL’RL’RLRL’RL’R’LR
(3,22,6)(4,23,7)(5,21,8)	L’RLRL’R’L’R’L’RL’R’LR’L’R’L’R’LRLR’
(0,22,19)(1,23,20)(2,21,18)	L’RLR’LRL’RL’R’L’R’L’RL’R’LR’L’R’LR’
(3,6,18)(4,7,19)(5,8,20)	L’RL’RLRLRL’R’L’RL’R’L’R’L’R’LRLR
(9,23,20)(10,21,18)(11,22,19)	L’RL’R’L’RLRLR’LR’LRLR’LR’L’R’LR’
(6,20,9)(7,18,10)(8,19,11)	L’RL’R’L’RL’RLRL’RL’RLRLR’L’R’LR’
(0,11,8)(1,9,6)(2,10,7)	L’RL’R’L’RL’R’LR’L’R’L’R’LR’LRL’RLR’
(0,22,6)(1,23,7)(2,21,8)	L’R’LRL’RL’RLR’LR’LRLRL’R’LRLR
(0,20,5)(1,18,3)(2,19,4)	L’R’LRL’RL’R’L’RL’RLRLR’L’RL’R’LR
(0,11,15)(1,9,16)(2,10,17)	L’R’L’R’LRLRLRL’RLRL’R’L’R’L’RL’R
(3,16,13)(4,17,14)(5,15,12)	L’R’L’R’LRL’R’L’R’LR’LR’L’RL’RL’R’LR
(3,12,15)(4,13,16)(5,14,17)	RLRLR’L’RLRLR’LR’LRL’RL’RLR’L’
(0,19,12)(1,20,13)(2,18,14)	RLRLR’L’R’LRLR’L’RL’R’L’RL’RL’RL’
(0,19,5)(1,20,3)(2,18,4)	RLR’LRLR’L’RL’RL’RL’R’L’RL’RLR’L’
(0,10,3)(1,11,4)(2,9,5)	RLR’L’RL’RLRL’RL’RL’RLR’L’R’LR’L’
(0,8,21)(1,6,22)(2,7,23)	RLR’L’RL’RL’R’LR’LR’L’R’L’RLR’L’R’L’
(0,19,22)(1,20,23)(2,18,21)	RL’RLRL’RLR’LRLRLR’LR’L’RL’R’L
(9,20,23)(10,18,21)(11,19,22)	RL’RLRL’RL’R’L’RL’RL’R’L’R’LRLR’L
(6,9,20)(7,10,18)(8,11,19)	RL’RLRL’R’L’R’LR’LR’L’R’LR’LRLR’L
(3,22,10)(4,23,11)(5,21,9)	RL’RL’RL’RLRL’RLR’L’R’LRLR’L’R’L’
(0,8,11)(1,6,9)(2,7,10)	RL’R’LR’L’RL’RLRLRL’RLR’LRLR’L
(3,6,22)(4,7,23)(5,8,21)	RL’R’L’RLRLRL’RLR’LRLRLR’L’R’L
(0,5,20)(1,3,18)(2,4,19)	RL’R’L’RL’R’LR’LR’LR’LRLR’LR’L’RL
(0,12,15)(1,13,16)(2,14,17)	R’LRLR’L’R’L’R’LR’L’RL’R’L’R’L’RLRL’
(3,13,10)(4,14,11)(5,12,9)	R’LRL’RLR’LR’L’R’L’R’LR’L’RL’R’L’RL’
(0,15,11)(1,16,9)(2,17,10)	R’LR’LRLRLR’L’R’LR’L’R’L’R’L’RLRL
(9,20,12)(10,18,13)(11,19,14)	R’LR’L’R’LRLRL’RL’RLRL’RL’R’L’RL’
(9,20,17)(10,18,15)(11,19,16)	R’LR’L’R’LR’LRLR’LR’LRLRL’R’L’RL’
(3,18,15)(4,19,16)(5,20,17)	R’LR’L’R’LR’L’RL’R’L’R’L’RL’RLR’LRL’
(3,13,16)(4,14,17)(5,12,15)	R’L’RLR’LR’LRL’RL’RLRLR’L’RLRL
(0,3,11)(1,4,9)(2,5,10)	R’L’RLR’LR’L’R’LR’LRLRL’R’LR’L’RL
(3,18,6)(4,19,7)(5,20,8)	R’L’R’L’RLRLRLR’LRLR’L’R’L’R’LR’L
(0,6,22)(1,7,23)(2,8,21)	R’L’R’L’RLR’L’R’L’RL’RL’R’LR’LR’L’RL
(0,12,16)(1,13,17)(2,14,15)	LRLRLRLR’LRLRL’R’L’RL’R’L’RL’R’L’
(0,20,15)(1,18,16)(2,19,17)	LRLRLRL’RL’RLRLR’LR’L’RL’R’L’R’L’
(0,18,9)(1,19,10)(2,20,11)	LRLRLRL’RL’RL’RLRLRLRL’RL’R’L’
(3,23,12)(4,21,13)(5,22,14)	LRLRLRL’R’L’RLR’LRL’R’L’RLRL’R’L’
(3,14,23)(4,12,21)(5,13,22)	LRLRLRL’R’L’R’L’R’LR’L’R’L’R’LRLR’L’
(0,15,20)(1,16,18)(2,17,19)	LRLRLR’LRL’RL’R’L’R’LR’LR’L’R’L’R’L’
(3,16,9)(4,17,10)(5,15,11)	LRLRL’RLR’LRL’R’L’RLR’LRL’RL’R’L’
(6,9,19)(7,10,20)(8,11,18)	LRLRL’RL’RL’RLRLR’LR’L’RLR’L’R’L’
(6,17,10)(7,15,11)(8,16,9)	LRLRL’RL’R’LR’LRLRL’RL’RLR’L’R’L’
(6,19,9)(7,20,10)(8,18,11)	LRLRL’R’LRL’RL’R’L’R’LR’LR’LR’L’R’L’
(6,10,17)(7,11,15)(8,9,16)	LRLRL’R’LR’LR’L’R’L’RL’RLR’LR’L’R’L’
(0,16,12)(1,17,13)(2,15,14)	LRLR’LRLR’LRLR’L’R’L’RL’R’L’R’L’R’L’
(3,9,16)(4,10,17)(5,11,15)	LRLR’LRL’R’L’RLRL’RL’R’L’RLRLR’L’
(0,9,18)(1,10,19)(2,11,20)	LRLR’LR’L’R’L’R’L’R’LR’LR’LR’L’R’L’R’L’
(0,23,8)(1,21,6)(2,22,7)	LRLR’L’RLRLRL’RL’R’L’R’LRLRL’R’L’
(3,12,23)(4,13,21)(5,14,22)	LRLR’L’R’LRLR’L’RL’R’LRLR’L’R’L’R’L’
(3,14,22)(4,12,23)(5,13,21)	LRLR’L’R’LRLR’L’R’L’R’L’RLRL’R’LR’L’
(0,8,23)(1,6,21)(2,7,22)	LRLR’L’R’L’RLRLR’LR’L’R’L’R’LRL’R’L’
(0,22,10)(1,23,11)(2,21,9)	LRL’RLRL’R’LR’LRLRL’RL’RL’R’LR’L’
(3,10,8)(4,11,6)(5,9,7)	LRL’RLRL’R’L’R’L’R’L’RL’RL’RL’RLR’L’
(0,10,22)(1,11,23)(2,9,21)	LRL’RLR’LR’LR’L’R’L’RL’RLR’L’R’LR’L’
(9,21,15)(10,22,16)(11,23,17)	LRL’RLR’L’RLRL’R’LR’L’RLRL’RLR’L’
(3,22,14)(4,23,12)(5,21,13)	LRL’RLR’L’R’LRLRLRL’R’L’RLRL’R’L’
(6,14,20)(7,12,18)(8,13,19)	LRL’RL’RLRLRL’RL’R’L’R’LRLR’LR’L’
(6,9,18)(7,10,19)(8,11,20)	LRL’RL’RLR’L’R’L’RL’RLRLRLR’LR’L’
(6,20,14)(7,18,12)(8,19,13)	LRL’RL’R’L’RLRLR’LR’L’R’L’R’LR’LR’L’
(6,18,9)(7,19,10)(8,20,11)	LRL’RL’R’L’R’L’R’LR’LRLRL’R’LR’LR’L’
(3,23,10)(4,21,11)(5,22,9)	LRL’R’LR’LRLR’L’R’L’R’L’RL’RLR’L’R’L
(3,8,10)(4,6,11)(5,7,9)	LRL’R’LR’LR’LR’LRLRLRLR’L’R’LR’L’
(3,13,19)(4,14,20)(5,12,18)	LRL’R’LR’L’RL’R’L’R’L’R’LR’L’RL’R’L’RL’
(9,15,21)(10,16,22)(11,17,23)	LRL’R’LR’L’R’LRL’RLR’L’R’LRL’R’LR’L’
(3,23,14)(4,21,12)(5,22,13)	LRL’R’L’RLRLRL’RLRLRLR’L’R’L’R’L’
(0,7,12)(1,8,13)(2,6,14)	LR’LRLRLR’LRLR’L’RL’R’L’RL’RL’RL’
(3,12,19)(4,13,20)(5,14,18)	LR’LRLRL’RL’RL’RLRLRLRL’RL’RL’
(3,6,14)(4,7,12)(5,8,13)	LR’LRLRL’R’LR’LRL’RLRLRLR’LRL’
(3,9,7)(4,10,8)(5,11,6)	LR’LRLRL’R’L’RLR’LRL’R’L’RLRL’RL’
(3,19,13)(4,20,14)(5,18,12)	LR’LRLR’LRL’RLRLRLR’LRL’RLR’L’
(0,5,11)(1,3,9)(2,4,10)	LR’LRLR’L’RL’R’LR’L’R’L’RL’R’LR’LRL’
(3,8,13)(4,6,14)(5,7,12)	LR’LRL’RL’R’LR’LRLR’LRL’RL’RL’RL’
(3,6,21)(4,7,22)(5,8,23)	LR’LRL’RL’R’L’RL’RLRLR’LRLR’L’RL’

Triangle triangle pure corner orientation algorithms

(see data model above for starting position and label meanings)

Effect	Alg
(12,14,13)(21,22,23)	LRLR’L’R’LRLR’L’R’LRLR’L’R’
(6,7,8)(15,17,16)	L’R’L’RLRL’R’L’RLRL’R’L’RLR
(12,13,14)(21,23,22)	RLRL’R’L’RLRL’R’L’RLRL’R’L’
(6,8,7)(15,16,17)	R’L’R’LRLR’L’R’LRLR’L’R’LRL
(9,11,10)(18,19,20)	LR’LRLR’L’R’LRLR’L’R’LRLR’L
(9,10,11)(18,20,19)	L’RL’R’L’RLRL’R’L’RLRL’R’L’RL’
(3,4,5)(9,11,10)	LRL’R’LR’L’R’L’RLRL’R’L’RLRLR’
(0,2,1)(18,19,20)	LR’L’R’L’RLRL’R’L’RLRLR’LRL’R’
(3,4,5)(18,20,19)	L’RLRLR’L’R’LRLR’L’R’L’RL’R’LR
(0,2,1)(9,10,11)	L’R’LRL’RLRLR’L’R’LRLR’L’R’L’R
(0,1,2)(18,20,19)	RLR’L’RL’R’L’R’LRLR’L’R’LRLRL’
(3,5,4)(9,10,11)	RL’R’L’R’LRLR’L’R’LRLRL’RLR’L’
(0,1,2)(9,11,10)	R’LRLRL’R’L’RLRL’R’L’R’LR’L’RL
(3,5,4)(18,19,20)	R’L’RLR’LRLRL’R’L’RLRL’R’L’R’L
(3,5,4)(21,22,23)	LRLRLRL’R’L’RLRL’R’L’RLRL’R’LR’L’
(3,4,5)(21,23,22)	LRL’RLR’L’R’LRLR’L’R’LRLR’L’R’L’R’L’

Meet in the Middle Graph Search

Sun, 07 Mar 2021 00:00:00 +0000

Background

I’ve been working on a puzzle game for Android called Looping Dice. It’s all about sliding squares around a grid try to match a pattern while using the fewest number of moves.

As part of creating levels for the game - I wanted to create a solver. This was useful for double checking that levels were solvable and also for setting the threshold where I give the use three stars on each level.

Breadth First Search

My first idea was to model this problem as a graph search. We treat each state that the puzzle can be in as a node - and think of each valid move as an edge. Then, given a start and end state, we can implement breadth first search as follow:

create an empty queue of puzzle states for things we need to explore
create an empty set of puzzle states so we know what we've explored already
insert the initial state into both the queue and the set
while (the queue is not empty){
   compute neighbors of the state at the front of the queue
   check if any of the neighbors are the goal state
   add each neighbor to the set of seen states
   if any neighbors are new to us, also add them to the queue to explore later
}

I think people who read my blog are probably familiar with BFS but let’s take a second to review why this works. Using the queue to order which nodes get explored means that this algorithm explores all nodes at distance N from the start before it visits any nodes of distance N+1. This also means that the first time we encounter the goal node - we are guaranteed to have done so by a shortest path.

The downside here is very similar to the upside - we always visit all nodes distance N from the state before we visit any at distance N+1. When the distance from the start to the end is large and when the branching factor from each node is large - this can be a huge number of nodes to explore before we find the goal.

The puzzle that motivated me to consider a better approach had 16 neighbors from each state and had an optimal solve length of 8 moves. It took my unoptimized BFS solver around 90 seconds to solve.

The idea of Meet in the Middle search

When humans try to solve puzzles like mine or like a 15 puzzle, we use heuristics to get closer to the goal, even if we don’t have a complete plan for how to finish the solve. To phrase it differently - we have an idea of what states might be near the end, and instead of aiming for the end directly, we aim for that cloud of nearby states.

I decided implement this using an approach I’d heard of but never seen in use called “Meet in the Middle” (MITM). I would start exploring from both the start and the end, and declare victory when either side found a state that the other one had previously found. Much like the BFS above, the first time these flood-fill searches encounter each other ought to be a shortest path, since both are exploring length N paths before starting on length N+1 paths.

First Implementation

Skipping over some details again, the main part of my algorithm looked like this:

create two queues of states to explore
create two a set for states seen by the forward exploration and another for backward
while (either queue is nonempty) {
  explore the state at the front of the forward queue as in BFS
  when you look at new nodes, also check if they are in the set of states seen by the backward exploration

  explore the state at the front of the backward queue as in BFS
  when you look at new nodes, also check if they are in the set of states seen by the forward exploration
}

I tried this new approach on the puzzle above and was shocked to see that it took 0.01 seconds to find an 8 move solution. This was different from the one found by the BFS implementation but it was also correct. I added some logging to both implementations to see how many states each one explored before it arrived at a solution. The BFS approach’s set saw 414764 distinct states before it arrived at the goal. In contrast the two sets used in the MITM approach had seen 2934 distinct states and 3069 distinct states before they found a shared state. No wonder it was so much faster!

Discovering a bug

While making some levels, I found a case where the solver claimed the shortest solution was in 6 moves - but I’d already found a 5 move solution on my own. What was going on?

Recall that in BFS, we guarantee that the first path we find is the shortest by showing that “if there was a shorter path, we would have found it earlier”.

Also note that in MITM, when the forward and backward explorations find their first shared state, it is necessarily on the “frontier” of the both of their BFS’s. By the same logic as above - if it wasn’t then we would have found it earlier.

Finally, consider this reframing of MITM: each time we discover a new node (let’s say distance N), and we compare it to a node on the other BFS’s “frontier” (let’s say distance M), we’re effectively checking if a particular solution of length N+M is valid. If the two nodes are equal, the solution is valid, and if they are different, then the solution doesn’t work. (In practice, this comparison is set-containment so it’s O(1) to compare against the whole frontier but it’s useful to imagine that we’re comparing new nodes against existing ones one-by-one.)

So in this bug, both forward and backward search had finished with all distance 2 nodes and were both starting to discover new nodes at distance 3 from the start/end. Each time one of these nodes was discovered, it was checked against the “frontier” of the other BFS.

Each comparison was checking for the existence of some length 5 solutions (self-length of 3, other-length of 2) and length 6 solutions (self-length and other-length both 3). That’s bad because it means we are looking at some length 6 candidate solutions before we’ve considered all length 5 solutions. This throws away the shortest-path guarantee of BFS!

This doesn’t happen for all searches but that’s exactly what happened in this case. Because of the arbitrary order that nodes are discovered, a length 6 solution showed up before we had the chance to see all length 5 candidates and note that one is correct.

Second Implementation

Once I understood the bug, the fix wasn’t conceptually hard. I had to keep the “frontier” of each BFS at a constant distance while I discovered nodes in the other one. After the refactor, the code was structured like this:

create two queues of states to explore
create two a set for states seen by the forward exploration and another for backward
target_depth = 1
while (either queue is nonempty) {
  explore forward as in BFS until you've seen all nodes distance target_depth from the start
  when you look at new nodes, also check if they are in the set of states seen by the backward exploration

  explore backward as in BFS until you've seen all nodes distance target_depth from the end
  when you look at new nodes, also check if they are in the set of states seen by the forward exploration

  increment target_length
}

Future Work

In my last implementation, I always alternate between forward and backward exploration. I suspect there might be some slight efficiency gains by using some heuristic (queue-length?) to decide which one to explore on each cycle of the outer loop. Doing so without benchmarks felt like premature optimization and at this point, the solver is fast enough that I don’t think I care. Maybe at some point I’ll need it to be even faster than it is today and look into that among other optimization ideas.

Closing Thoughts

I ran my revised solver against all the levels I’d made so far (around 100) and found only a single case where it did better than the non-optimal solver. It’s quite lucky that I stumbled into a case where the previous MITM solver had a non-optimal solution.

Magnetic Hinge Arrangement

Sun, 28 Feb 2021 00:00:00 +0000

Background

Yesterday, Oskar van Deventer posted a video of a new puzzle he’d developed. If you watch the video, you’ll see three cubes where each one has magnetic protrusions along each edge. The protrusions on each cube are arranged so that when any pair of cubes are connected edge-to-edge, they form a magnetic hinge.

Oskar’s puzzle has three cubes, but I was curious what arrangements one might use if designing this puzzle with an arbitrary number of cubes. This boils down to the question: Arrange the numbers 1-N into a sequence with duplicates allowed such that every pair of numbers is adjacent somewhere in the sequence.

Analysis

We can put some upper and lower bounds on the length of a minimal sequence as follows:

Upper bound: given N objects, there are C(N,2) = N*(N-1)/2 pairs that need to be accounted for. One sequence that satisfies our question is “all pairs printed one after another”. For example, when n=4, our sequence might be 121314232434. This sequence has length N*(N-1).

Lower bound: Given N objects, there are C(N,2) pairs that need to be accounted for. Each element we add to the sequence creates one new pair. Therefore, a sequence containing C(N,2) pairs must be at least 1+C(N,2) elements long.

When N is even, I believe the lower bound cannot be achieved. This is because most elements don’t appear at either end of the sequence so they have an even number of neighbors. But when N is even, an odd number of those are mandatory and one is extra. I believe the sum of these “extra” neighbors makes it impossible to get to the lower bound sequence length.

Embracing Randomness

Rather than try to be clever with constructing these sequences, I decided to do a whole lot of guess, test, and revise. I wrote a bit of C++ to do so:

The first one generates sequences made up of |symbols| different values and of length |len|.

std::vector<int> make_candidate(int symbols, int len) {
  std::vector<int> ret(len, 0);
  for (int i = 0; i < len; ++i) {
    ret[i] = rand() % symbols;
  }
  return ret;
}

The next one checks if a sequence satisfies our condition. It stores each pair in an unordered set by hashing it. Then it checks if enough pairs have been found by comparing against a global constexpr that was computed based on the number of symbols being used (also constexpr).

bool check_candidate (const std::vector<int>& v) {
  std::unordered_set<int> seen;
  for (int i = 0; i < v.size() - 1; ++i) {
    if (v[i] != v[i+1]) {
      int low = std::min(v[i], v[i+1]);
      int high = std::max(v[i], v[i+1]);
      seen.insert(100*high + low);
    }
  }
  return seen.size() >= pairs;
}

From there, I just ran trials continuously until I got results I liked. By tweaking the lengths of the sequences I was generating, I could slowly hone in on the optimal length.

A nice feature of this approach is that nothing needs to be remembered from trial to trial. This means the program uses very little memory and can be left running as long as I am willing to wait.

For small values of N, this worked quite well. But as N got to 7 or 8, valid sequences became harder and harder to find. I decided to up the length of sequence I was checking to increase the chances of finding valid sequences but add some postprocessing to try to get results that were as good as possible.

Optimizing Random Output

I came up with two simple ways to shorten a valid sequence.

The first was to filter out letters that were adjacent to themselves. This doesn’t effect correctness so it’s always OK to to do.

The second was to test the sequences with the first/last elements removed. In a lot of cases, the first pair would also appear elsewhere in the sequence so removing the first element was fine. Likewise with the last pair and the last element.

Results

By combining these techniques and doing a lot of trials, I came up with the following results:

4: 12324314

5: 12342541531 (hits lower bound)

6: 123453463142615256

7: 1234537257182413847851 (hits lower bound)

8: 12342562754783581641748673158263

9: 1234354256768419467461829351372586289638715975

Wrap Up

Having done all this, I plugged my results into OEIS, and found this sequence whose description is the same as my problem except it cares only about the length of the sequence and not about its construction. The programs there to calculate it suggest some sort of counting argument that could maybe be converted into a construction but I’m not sure there’s enough detail for me to do so.

Using Bandaged Cube Explorer to solve 0x20108000000C03

Sun, 20 Dec 2020 00:00:00 +0000

Background

In my previous post, I introduced a tool for exploring the shape space of bandaged 3x3x3 Rubik’s cubes and suggested that it might be useful for solvers. In this post, I’m going to walk through how I how I used it to solve one bandaged configuration, 0x20108000000C03.

I decided to name this puzzle “cofortress” since its shape graph has the same structure as the one for Bandaged Fortress (a.k.a. 0x30000010048883)

Analyzing the cube

For consistent naming, I assume that the cube is always oriented with white on the U face and green on the F face.

Cofortress has a small state space, just 42 nodes and 60 edges arranged in one big loop. As you walk around the loop, there is a repeated pattern - “half turn, half turn, quarter turn (solver picks direction)”. This suggests that our sequences will have one of two forms:

Go around the loop
Go partially around the loop, until you hit a quarter turn. Do that quarter turn twice to swap some pieces, then undo the path around the loop.

There are arguably others where we take a more complex back-and-forth path around the loop but all of these can be written as combinations of the above so I don’t really consider them.

If we look closely at the states where a quarter turn is possible, we notice that they always happen on a face with with two 1x1x3 blocks and two regular edges. This means our second type of sequence should always swap two edges and swap the 1x1x3 blocks.

By the same reasoning, following the whole loop will have the same effect on the other bandaged blocks and the unbandaged corners no matter which direction we choose to take our quarter turns. It happens to be the case that this effect is nothing; so when cofortress is solved by shape, our 1x1x2 blocks and unbandaged corners are always solved by color.

What is left for us to solve are the 9 pieces on cofortress that can move around when the puzzle is solved by shape:

The two 1x1x3 blocks can swap with each other
The {UF, UL, BL, FL, FR, DL, DR} edges

But wait - when cofortress is solved by shape, a D2 move swaps the 1x1x3 blocks. So now we’re down to two remaining challenges; getting to the solved shape, and finding ways to move unbandaged edges around in the solved shape.

Solving the shape (and scrambling the puzzle)

This might sound surpassing if you’ve never held a bandaged puzzle but scrambling them can be a challenge in its own right. On cofortress, the turns out to be almost the same challenge as solving the shape.

Looking closely at our shape graph, each state has either one or two faces that can turn. That means that we can walk the loop (without needing to see it) by always turning a different face than the one we turned previously. Even better, we use the “half turn, half turn, quarter turn” pattern to guide us. The first half turn will always effect just one of the 1x1x3 blocks. The second half turn will effect the other, then the quarter turn will be on the face that now contains both of them.

I case you’d like something a big less handwavey, here’s a sequence to follow for scrambling cofortress:

B2 U2 F*
L2 B2 R*
D2 R2 D*
B2 D2 B*
R2 F2 L*
U2 R2 D*

Where * means either a clockwise or counterclockwise quarter turn. I’ve found that even one repeat of this sequence is a decent scramble but feel free to go through it a few times.

When it comes to returning cofortress to its solved shape, the procedure is similar to the scramble. Put both 1x1x3 blocks on the same face, then follow the “half turn, half turn, quarter turn” sequence until both are solved relative to the centers.

Edge Orientation

People who haven’t spent much time with a Rubik’s cube sometimes think that it is a puzzle about manipulating 54 independent stickers. In fact, that puzzle is made of a core, eight corners and twelve edges. Ignoring the core for a moment, the corners and edges both have a position and an orientation on the cube. Its possible to put all pieces in the correct position, but have some 3-sticker corners twisted or some 2-sticker edges flipped in place.

On cofortress, the constraints imposed by the bandaging mean that when we are in solved shape, or corners are always oriented correctly. In the first draft of this solution, that made me overlook the fact cofortress can still have flipped edges. Rather than walk you through my faulty thinking, let’s discuss what it means for an edge to be oriented and then skip ahead to when I corrected myself.

Speedcubing methods provide a nice definition for edge orientation. We consider an edge oriented if it can be put into place (on an unbandaged Rubik’s cube) without using the F and B turns (or the slice turns). If you don’t have a lot of experience solving a Rubik’s cube, the speedcubing definition can be hard to visualize so here’s a equivalent procedure that spells things out more explicitly.

  # Assume the cube is oriented with white on top and green in front
  # If using a different color scheme or orientation, relabel colors accordingly
  if edge is on the U or D face:
    let C1 be the color of the sticker on the U/D face
    let C2 be the color of the other sticker on that edge
  else:
    let C1 be the color of the sticker on the F/B face
    let C2 be the color of the other sticker on that edge

  if C1 is white or yellow:
    the edge is oriented correctly
  if C1 is orange or red:
    the edge is flipped
  if (C1 is green or blue) and (C2 is red or orange):
    the edge is oriented correctly
  if (C1 is green or blue) and (C2 is white or yellow):
    the edge is flipped

Edge orientation is a broadly useful concept for all kinds of solvers.

The ZZ method starts solve by orienting all edges - then takes advantage of this invariant in later steps.
Competitors in the Fewest Moves Challenge event in the World Cubing Association have a number of techniques for finding efficient solutions to a scramble. One popular technique is Domino Reduction, which uses edge orientation for a similar reason - this invariant can be taken advantage of later in the solve.

In the case of our bandaged puzzle, we care about edge orientation because we have a lot less flexibility with edge orientation than with edge permutation so our plan is to orient all edges before permuting them.

Moving Edge Around

With our analysis out of the way, let’s start to look at some concrete sequences on cofortress. We’ll begin with those of the second type mentioned above, conjugates setting up to a half turn. We know that these will swap the two 1x1x3 blocks and two unbandaged edges so let’s apply them to a cube and see which edges are swapped. To keep these compact, I’m using the twisty puzzles shorthand for conjugates, [A : B] = A B A^-1 where A and B are arbitrary sequences.

Here are 9 sequences that swap the two 1x1x3 blocks and also swap a pair of edges without modifying their orientation.

id	sequence	edges swapped
perm 1	D2	DL, DR
perm 2	[B2 U2 : F2]	FL, FR
perm 3	[D R2 U2 : L2]	FL, BL
perm 4	[B2 U2 F L2 B2 : R2]	UL, DR
perm 5	[D R2 U2 L F2 R2: B2]	UF, DR
perm 6	[D R2 U2 L F2 R2 B D2 B2 : D2]	UL, FL
perm 7	[D R2 U2 L' F2 R2 B D2 B2 : D2]	UL, BL
perm 8	[D R2 U2 L F2 R2 B D2 B2 D R2 D2 R B2 L2: F2]	FL, DR
perm 9	[D R2 U2 L F2 R2 B D2 B2 D' R2 D2 R B2 L2: F2]	UL, DL

Next we have 3 sequences that swap the two 1x1x3 blocks and also swap a pair of edges and also modify the orientation of both swapped edges.

id	sequence	edges swapped
flip 1	[B2 U2 F L2 B2 R D2 R2 : D2]	UF, FR
flip 2	[B2 U2 F' L2 B2 R D2 R2 : D2]	UF, FL
flip 3	[D R2 U2 L' F2 R2 B D2 B2 D R2 D2 R B2 L2: F2]	DL, BL

And now let’s talk about sequences of the first type, where we make a circuit around almost the whole shape space of cofortress. I found these did a lot more than the type-2 algorithms above so they weren’t as useful for moving just a few edges. Some of them were nice for flipping more than two edges at a time, but this is an optional optimization.

id	sequence	edge slots flipped
circuit 1	D R2 U2 L F2 R2 B D2 B2 D R2 D2 R B2 L2 F U2 B2	UF, FL, DL, DR
circuit 2	D R2 U2 L' F2 R2 B' D2 B2 D R2 D2 R B2 L2 F U2 B2	UF, BL, DL, DR
circuit 3	D R2 U2 L F2 R2 B D2 B2 D' R2 D2 R B2 L2 F U2 B2	UF, UL, DL, DR

Careful readers might have noticed that some of these sequences differ only by the direction of a quarter turn (i.e. perm 6 vs perm 7). But there are some variations of these algorithms that aren’t listed above. The sequences that I omitted are because they have the same effect as a sequence in the table. For example, replacing the D in sequence 3 with a D’ doesn’t change which pieces are swapped so including it would be redundant.

Using the Sequences

Like with edge flipping, our options for which slots can be swapped are somewhat limited. Some slots are easier to use than others. In particular, the UF slot is annoying to insert into but is critical for all flipping sequences. Here is a visualization of which slots can swap with which others without changing edge orientation.

So to bring it all together, we use the visualization and perm sequences above to set up flipped edges into positions where they are easy to orient correctly. We use the flip and cycle sequences to orient them. Finally we use the visualization and tables again to move the edges back to their solved slots.

It’s worth noting that all our perm algorithms are conjugates so their ends are the inverse of their beginnings. This means they can cancel quite a few moves when doing one after another. For example, consider perm 5 followed by perm 3:

[D R2 U2 L F2 R2: B2] [D R2 U2 : L2]
(D R2 U2 L F2 R2 B2 R2 F2 L' U2 R2 D') (D R2 U2 L2 U2 R D')
D R2 U2 L F2 R2 B2 R2 F2 (L' U2 R2 D' D R2 U2 L2) U2 R D'
D R2 U2 L F2 R2 B2 R2 F2 L U2 R D'

This is exactly the same as perm 5 except with the last L’ replace by an L. So if you know the next several sequences you are going to do, you can optionally save moves and time by predicting which moves will cancel and omitting them.

Final Thoughts on Cofortress

I quite enjoyed solving cofortress. Now that I have my method and notes organized, it only takes a few minutes to scramble and solve it. I really like how different the solve feels from an unbandaged 3x3x3.

I’m also happy with how my bandaged-cube-explorer tool guided my solve. It certainly would have been possible without the tool but I think it would’ve added a lot of toil with adding much enjoyment.

Bandaged Fortress

A small update - since writing this post I spent an evening analyzing and solving bandaged fortress. As expected, the solve feels very similar to cofortress. My solve’s outline looks the same - follow “half turn, half turn, quarter turn” until the puzzle is solved by shape, orient all edges, then permute all edges.

When I feel like coming back to this sort of bandaged puzzle, I think I may try one of 0x20100000000C03 or 0x30000000040203 next. The first one severs one of the bonds in cofortress resulting in a graph with a second loop. The latter one takes it a step further and moves a block to allow for 4x as many states as cofortress, arranged into 4 connected loops.

Bandaged Cube Explorer

Sat, 19 Dec 2020 00:00:00 +0000

tl;dr, I made a program for exploring bandaged configurations of the 3x3x3 Rubik’s cube. You can play with it here. If you are interested in the source code, it’s available on my github. Read on to learn about what it does and how it works or skip to the bottom for some links to nice examples.

Bandaged Cubes

I recently came across this video about how to think about bandaged twisty puzzles. The video is not long and does a good job of introducing the premise of bandaging a puzzle so I’ll skip over explaining that here.

Before watching that video, I had been aware of the idea of bandaging and had even tried solving a few bandaged puzzles, but something hadn’t clicked for me. My experience was that simplest ones were too easy and didn’t present and new challenges; but that harder ones were too difficult to even formulate an approach. That video was exciting because the “loops in a graph” strategy seemed like it could be applied to many other bandaged configurations.

I was also delighted about the way the threefold symmetry of the puzzle got reflected into threefold symmetry in the graph. When I first tried to get into bandaged puzzles, I found a few docs online containing collections of named configurations like this doc, and this other doc. What they both lacked was guidance on what kind of experience to expect when solving each puzzle. The threefold symmetry of the puzzle and the graph gave me hope that a bandaged puzzle’s state graph might give a hint to what kind of solve to expect.

Playing with d3.js

Pretty early in my design process, I came across a github project where someone had already done exactly what I was imagining. Even better, the author included a csv of all distinct bandaging schemes and some metadata about each one. There were a few things I didn’t like about it though.

It required the user to run python - meaning it was inaccessible to many potential users.
I couldn’t get the cube drawings to work for me.
Sometimes the graphs it generated were so tangled up that it was impossible to see what was going on.

I decided I would make my own version to address these points. First of all, my version would be a webapp so it could be used from more platforms. And second, my version would be interactive so the user could zoom and shift nodes around as needed.

The platform I chose was d3.js’s force directed layout. The idea is that each node is given a slight negative charge and each edge is given a slight spring force. The charge means that nodes spread out away from each other and the spring force means that connected nodes stay near each other. For many graphs, this sort of layout does a good job at both global and local layout. Best of all, d3.js supports a huge amount of customization and a huge number of features.

I decided to avoid labels on nodes or edges because I was worried they would make the graph unreadable as it grew. Instead I decided to color code my edges according to which face was was turned and to indicate direction with an arrowhead and to add mouseover previews for each node’s meaning. To deal with the varied size of state graphs, I used d3’s standard panning and zooming features. To deal with awkward graph layouts, I added interactive dragging so the user could untangle graphs manually.

Drawing self edges

One limitation I ran into with d3 was was drawing edges from nodes to themselves. By default, this drew a line whose start and end points were the same - a.k.a. nothing. I found a helpful answer on github how to turn these into arcs from the point to one very nearby. This worked well, and as a side benefit, I could modify my choice of nearby point to change the orientation of the loop.

One nice example of this is the graph for an unbandaged Rubik’s cube. On this cube, all 6 face loop back to the only state. As a solver, this sort of self edge is quite useful so I was happy to be able to show all 6 so distinctly.

On the way to finding that answer, I experimented with a different approach where I added a not-drawn node in the middle of each edge and used it to make edges curve. This turned out not to solve the self edge problem but I liked it so it got to stay.

Reverse Engineering the Spec

One problem I needed to solve before getting started was how users would input bandaged cube IDs. I decided to use the scheme devised by Andreas Nortman since it seemed to be the standard. The way it works is to define each bandaged cube by the presence or absence of 54 “bonds”. Each bond is given an offset in a 54-bit integer, usually represented in hexadecimal.

This representation is nice because it makes some operations very easy. For example, in order to test if a face can be turned, you only need to check if any of the 9 blocking bonds are present. Similarly, turning a face means doing a permutation of bits representing the bonds on that face. There was just one problem - I couldn’t find any documentation for which bonds corresponded to which offsets.

To make a long story short - I managed to reverse engineer the mapping by looking at the code of the github project mentioned above. I still don’t see the logic behind the mapping but I’m sure there is one. I made sure to document the mapping as much as possible in my code and with a helper image in the my project’s README.

There are a few things I don’t like about this about scheme. The first is that it is very unreadable for humans. This is probably unavoidable given that there are hundreds of thousands of possible signatures but it is still a shame. The second is that representations can be ambiguous. Imagine a cube where both the U and F centers are bonded to the UF edge. This makes the U and F faces permanently blocked - effectively bonding their centers to the core as well. I user might reasonable choose to write those core bonds or omit them. I think the csv on paul_cube_bandaged_graph has the right idea - it always always explicitly write the implied bonds. In the future, it might be nice to have a tool to “canonicalize” signatures so that it would be easy to tell when two people are talking about the same bandaged cube.

Drawing the cubes

The first thing I built was a way to preview what a given bandaged configuration looks like. Initially I wanted to draw this to the same svg as my nodes and edges but that turns out to be a problem once I added zooming. Rather than learn more about svg scaling in d3, I took a shortcut and put the preview on a second svg that is layered behind the main one. The one drawback is that a very busy graph will now obscure the legend a bit. I didn’t see that as a big problem since the user can just zoom out to create more whitespace.

Bit manipulation in javascript

As I mentioned above, the data format makes it pretty easy to check which faces can be turned and to compute the result of a turn using bit manipulation. The default number type in javascript aren’t integers so you can’t do bitwise math. Luckily, js now has a BigInt type which works approximately how I want. It supports common bitwise operations but it doesn’t guarantee O(1) for all them. It also doesn’t lend itself well to tools like my favorite tool for optimized bit swizzling.

I decided to do the responsible thing and ignore performance until it was problem. Even on the largest graphs, computing all necessary turns only takes a few seconds so I haven’t gone back to optimize this.

Building graphs from user input

Once I had all the groundwork in place, this part turned out quite easy. I do a breadth first search of the graph and keep track of all the nodes and edges that exist. When recording edges, I note which turn caused them to exist so I know which color to draw them.

In an earlier version, I planned to dedupe nodes that could be turned into each other by cube rotations or mirroring. My idea was that this could shrink the size of problematically large graphs. In the end I decided not to do this because rotations like this usually aren’t useful as a solver.

Future work

I’m relatively happy with this project. It does exactly what I set out to do, and the graphs are pretty satisfying to play with. If I ever come back to this, I have a few ideas I might implement to improve it further.

When zooming out, nodes become quite small and hard to click. It would be fun to size nodes based on the size of the graph so things continue to look good after zooming. To do this, I need to make sure my arrowheads don’t sink into the nodes that point at. My arrowhead code was copied from a stackoverflow answer so I’ll need to understand it to modify it.

Many graphs contain states that there’s no reason to visit. For an example, let’s take a look at the graph for the cube in the youtube video from the top of this post. The graph has some chains for 4-cycles that look almost like lace:

The reason for these 4-cycles is that turning a face four times returns it to its initial position. In the screenshot above, a solver progressing along that arc can either do one turn of the green face clockwise, or (equivalently) three turns counterclockwise. The states reached along the three counterclockwise turns are useless as a solver. There are also some features of the graph that looks like this:

This 4-cycle represents a face that can be turned in one position, but such that turning that face block all other moves until the face is returned to its starting position. Once the cube has been returned to its original bandaged signature, there is no reason to visit these states.

I think it would be interesting to add a mode where extraneous nodes like these are removed. Doing this efficiently would be nontrivial but it might make some larger graphs lag less and be easier for a human to understand.

Nice examples

In the process of writing this post, I’ve looked at a few hundred graphs to see what they look like. Here are a few that I thought were especially interesting or pretty.

0x108400f7a00631 starts out a bit tangled and is satisfying to untangle.
0x80200084 has really interesting layers.
0x100400C7AC043D is very spread out
0x10000000000002 is impossibly tangled.
0x182800008 has nice 4-way symmetry
0xc63 looks like a face to me.
30000000040203 looks like 4 connected rings.
0x8000802005A0 takes a bit of prodding but I think it looks like the back of a fancy card.

If you come across any nice examples, please send me links. I’m always happy to look at a cool graph.

Using it to come up with solutions

In my next post, I’ll be writing about how I used this tool to help me come up with a solution to 0x20108000000C03. It is a puzzle where your options are tremendously limited and being able to visualize them clearly was key to coming up with a solution.

By coincidence, this puzzle has a graph-twin - 0x30000010048883 named “Bandaged Fortress” that others have solved. I’m excited to try that one as well and test my theory that the structure of the graph informs the experience of the solve.

Twisty Puzzles Intro

Sat, 19 Sep 2020 00:00:00 +0000

Personal History

When I was a teenager, one of my older brothers taught me to solve a Rubik’s cube. He gave me a handwritten sheet of notes on what to do in a bunch of cases and if I followed the sheet correctly, the cube would always end up solved. Eventually, I memorized the dozen or so move sequences from the sheet.

Later, my parents bought me a megaminx - a puzzle that is a lot like a Rubik’s cube except that it’s based around a dodecahedron. I was able to apply some of my knowledge from the Rubik’s Cube to the megaminx but got stuck on the last layer. Even though the puzzles were quite similar, I didn’t understand the seemingly-magic algorithms from my brother’s notes so I was lost when it came to adapting them to a new situation. Eventually I ended up looking up a solution online so I could solve the puzzle and at the time that felt satisfying.

Rediscovery

A few years ago, I saw a Youtube video about a puzzle I’d never seen before. I think it was a review of a mass produced version of Oskar van Deventer’s Redi Cube. I bought a copy and quickly felt the same frustration I’d felt with the megaminx - I didn’t have a strategy and I didn’t even know how to come up with a strategy. So again, I went to the internet and I found a tutorial for how to solve that puzzle.

Looking back, I regret how quickly I gave up. I feel like I deprived myself of the experience of building an understanding of a puzzle and the joy of coming up with a solution.

Nonetheless, solving a puzzle was still satisfying and I started to do research on what other puzzles were out there. It turns out that the Rubik’s cube was only the tip of the iceberg. At the time, I didn’t really have the framework to understand these puzzles but I still liked seeing videos of how they moved. They were like interactive sculptures!

What’s in a Solution

The sheet my brother gave me was one strategy for solving a Rubik’s cube, but it certainly wasn’t the only one. In fact, dozens of strategies exist for the Rubik’s cube! Lets zoom in a bit and compare two of them.

CFOP

Speedsolvers care about solving their puzzles as quickly as possible. This means their solutions need to optimize for sequences that can be executed with good ergonomics and preferably for low move count when possible. They also need to focus on patterns that can be recognized quickly - because looking around the puzzle for a piece wastes time.

To get a little more specific, the beginner-friendly version of the CFOP method has users learn around 15 algorithms for the different phases of the solve. At the highest level, CFOP-users learn sets of algorithms like ZBLL which consist of hundreds of move sequences for more optimally handling situations that come up during a solve.

Other speedsolving methods exist with different tradeoffs but most have the same property as CFOP that advanced users typically learn large numbers of algorithms in order to get faster. This isn’t to say that the only way to solve faster is to memorize large sets of algorithms, but the methods that speedsolvers use aren’t opposed to such algorithm sets.

Low Algorithm Count

In contrast here is a method for solving the same puzzle using only two algorithms. It is not optimized for speed, move count, or ergonomics. Instead, it is optimized understandability and ease of memorization.

Notably, the two algorithms are lengths 4 and 8. This is in sharp contrast with cfop which contains 15+ move algorithms in even the intermediate versions.

What I value in a solution

I think both of these methods are succeeding at their goals. CFOP is an effective speedsolving method that lets users start with a moderate number of algorithms and gives them the option to learn more in order to get faster. The two-algorithm method from that video is easy to learn and easy to remember.

I am not a speedsolver and I am not such a minimalist that I want a solution with just 2 algorithms. Ideally I would like my solutions to:

Be easy to remember
Be easy to execute without errors
Be flexible
Be understandable or even intuitive
Avoid long or tedious algorithms
Avoid large numbers of algorithms
Have some room for creativity to combine or skip steps
Be personal in some way

Techniques for Designing Solutions

Getting back to the story of my experiences with twisty puzzles, I wanted to stop learning solutions from others and start coming up with my own. There are many ways to do this but one common one is based on the group theory idea of a commutator. There’s a lot to say here so instead of writing it all, I’ll link you to this video from Mathologer who does a pretty good job.

Assuming you watched that video - you now know how to come up with your own solutions! So why am I writing a blog post about this? Well Mathologer glosses over some details that I think are quite interesting.

Finding magic sequences to isolate pieces is not trivial, especially on complex puzzles
The “trick” only applies if the puzzle is doctrinaire - meaning all moves are always available. Many interesting puzzles do not meet this definition and need additional strategy.
The video only covers “pure” commutators, where only one type of piece is permuted. When solving puzzles with many piece types, it can be convenient to ignore some piece types while focusing other others. In this case, deciding which order to address the pieces becomes an interesting part of finding a solution.

My Journey of Improvement

Over the last few years, I’ve been slowly improving my solving skills and growing my puzzle collection. At the start of 2020, I decided to push myself so I scrambled every puzzle in my collection (about 75 puzzles at the time), and attempted to solve all of them by the end of the year without consulting any outside help. Embarrassingly, this was the first time I’d ever scrambled a few of them.

It’s currently September and I’m on good pace toward that goal. My puzzle collection has also grown to about 100 puzzles (new ones were scrambled and counted toward my 2020 goal) and I only have three left to solve before the end of the year. I believe that my work so far has had the desired effect of making me a stronger puzzle solver.

That said, some of my solutions were quite ugly. For several puzzles, like the bagua cube, and the geared mixup, my solutions involved long (40+ moves) pure commutators. For some of the crazy 3x3x3 plus series, I got stuck on edge orientation issues and feel like I got out of them by luck.

In 2020, I thought this was fine, since my goal was to solve all puzzles - not to solve them well. But in 2021, I want to step up my game further. I want to focus on a smaller set of puzzles and find solutions that I am proud of. I want to solve each one more than once to make sure my solution covers all possible edge cases. Also, I want to do this with less use of digital puzzle simulators than in 2020 as a way to improve my puzzle visualization skills.

I haven’t decided whether I’ll consult other people’s tutorials in 2021. On one hand, finding the solutions myself feels more meaningful. On the other hand, I think I’m missing out on ideas that I could be learning from others.

Many of my solutions were written down on scratch paper and were probably lost. So moving forward, when I find a solution that I’m happy with, I’m going to try to document it on this blog for posterity. I may also do some smaller posts on misc puzzle ideas I had that I think are worth recording. These posts will not be tutorial and will probably be written for an audience that is already familiar with puzzles.

Very Random Siteswaps

Tue, 16 Jun 2020 00:00:00 +0000

tl;dr https://joshmermelstein.com/random-siteswap generates very random siteswaps. Read on to learn how it works.

Background

When James Buckland and I were working on juggling-graph, I sent him a worksheet from one of Matt Hall’s workshops to use for interesting examples. He turned that list into the “Random” button on that site. That button got me wondering - how would be generate siteswaps at random?

I did a bit of research and found a post from Jack Boyce, the author of jugglinglab. In it, he references this post from 1998 containing the following code:

/* gentest.c       Bijective siteswap generator        */
/*                                                     */
/* Jack Boyce (jbo...@physics.berkeley.edu)            */
/* July, 1998                                          */
/*                                                     */
/* Uses bijection to calculate all (b+1)^n siteswaps   */
/* of period n and no more than than b balls           */
/*                                                     */
/* Basic idea due to Colin Wright, Michael Kleber,     */
/* and many others                                     */

void convertone(int *in, int *out, int n) {
   int i, j, accum;
     
   for (i = 0; i < n; i++) {
      accum = out[i] = in[i];
      j = i;
      while (accum > 0) {
         j = (j+1) % n;
         if (in[j] < accum)
            out[i]++;
         else
            accum--;
      }
   }
}

void printthrow(int th) {
   printf("%c", th + ((th<10)?'0':('A'-10)));
}

void main(int argc, char **argv) {
   int i, bmax, n, *input, *output;

   if (argc != 3) {
      printf("Usage: gentest <ball limit> <period>\n");
      exit(0);
   }

   bmax = atoi(argv[1]);
   n = atoi(argv[2]);
   input = (int *)malloc(n * sizeof(int));
   output = (int *)malloc(n * sizeof(int));
   for (i = 0; i < n; i++)
      input[i] = 0;

   while (1) {
      convertone(input, output, n);
      for (i = 0; i < n; i++)    printthrow(input[i]);
      printf(" -> ");
      for (i = 0; i < n; i++)    printthrow(output[i]);
      printf("\n");

      i = n-1;
      while ((input[i] = (input[i]+1) % (bmax+1)) == 0)
         if (i-- == 0)
            return;
   }
}

His code works as expected, but I couldn’t figure out why it worked so I didn’t know how to extend it to support sync or multiplex patterns. Luckily, I did recognize the name “Michael Kleber” from the header comment - I know him through my work! Michael agreed to meet for coffee, and he gave me exactly the explanation I was looking for.

Cards Model of Vanilla Siteswap

First, we define a set of cards that look like this:

We’re going to generate our random siteswaps by drawing from a deck of these cards (with replacement). Here’s an example:

I’ve colored in various arrow to make things easier to follow. The first thing to notice is that every beat has one arrow “landing” on the bottom, and other arrow emerging from the bottom to some height. This is just like the conditions that make a siteswap valid.

The other thing to notice is that the cards divide space into evenly sized chunks. So we can count how many beats each arrow spends in the “air” before it lands back at the bottom of any card. If we do this for each arrow, we get the numbers {7, 2, 2, 3, 6}. And in fact, these cards can be viewed as a representation of the siteswap 72236.

So why is this cards model useful to us? Well every arrangement of cards is a valid siteswap - and every siteswap has exactly one arrangement of cards. This simplifies the problem from “generating random siteswaps” to “generating random sequences of cards”. And we can represent each card with the height its arrow rises up to; so now we just need to generate a random list of positive integers.

Extending to Sync

Now that I understood the vanilla case, I wanted to extend this to generating sync siteswaps. The idea is really similar! Instead of our cards just having one arrow on them, they need two arrows - one for each hand. We could also use a pair of vanilla cards to represent each sync beat but we nee to be careful. If the second card was a 1, that would turn the first throw into a 0x. Here’s an example of a hand of sync cards.

Can you tell what siteswap this is? Check the name of the image for help.

Extending to Multiplexes

Extending to multiplex is also not too difficult. Now, we allow more than one arrow to rise from the bottom of each card, and we also make sure that the same number of arrow go to the bottom of each card. For example, here are all cards of height 3 (ignoring the order that balls exit a multiplex).

Now that more than one arrow can hit the ground in a card, we need to modify our constraint on sync card pairs. The new constraint is the “the lowest height on the first half of a card must be higher than the number of arrows coming out of the second card. As before, this guarantees that no 0x’s will appear.

Problems with multiplicity

Of the 8 multiplex cards shown above, there are 4 from the vanilla deck, and 4 new ones - so if we pick randomly then we have a 50/50 shot of introducing a multiplex. But what happens as the max arrow height goes up?

Well when there are n heights to choose from, there are 2^n possible cards, and only n+1 are vanilla. When N is large, that’s a tiny fraction!

So if we generate cards uniformly at random, we’ll end up with nearly every throw being a multiplex. There’s nothing wrong with this but I think those patterns aren’t that interesting. I decided to make high multiplicity throws much less likely to steer the program toward patterns I found interesting.