tutorial | Mohammad Moshtaghi

Solving the Molecube by Reduction

Mon, 06 Jan 2020 13:00:00 -0700

My sister-in-law surprised me with a Molecube for Christmas, which combines the logic of a Sudoku puzzle with the mechanics of a Rubik’s cube. Each ball on the Molecube is one of nine colors, and the goal is to reconfigure a shuffled Molecube so each of its faces has all nine colors on it.

It turns out that solving the Molecube is a wonderful exercise in what computer scientists call reduction, which involves transforming a problem we don’t know how to solve into one that we do, solving that version, and then translating the solution back into the original problem. In this post, I’ll give a reader-friendly primer on reduction, outline a reduction from the Molecube to the Rubik’s cube, and then wrap up by solving the Molecube with a standard Rubik’s cube algorithm.

If you’re interested in solving the Molecube yourself (and perhaps you’re here looking for hints), I’ve created a worksheet you can use and will point out when you should skip ahead in the post so as to avoid spoiling this delightful puzzle.

Reduction: There and Back Again

Say we have a problem $A$ that we don’t know how to solve and another problem $B$ that we do know how to solve. Said another way, we have an “algorithm” that can answer any question asked in the form of problem $B$, but we have no such algorithm for problem $A$ questions. The whole idea of reduction is to:

Take a problem $A$ question (which we don’t know how to answer) and “transform” it into a problem $B$ question (which we do know how to answer).
Use the “algorithm” for problem $B$ questions to get an answer for our transformed problem $A$ question.
Translate the algorithm’s answer back into the context of problem $A$.

That’s it. We use a known algorithm (for problem $B$) as our workhorse for a new and unknown problem (problem $A$), and out pop solutions for our unknown problem! This powerful technique underlies almost all of theoretical computer science, giving us a tool to relate difficult problems to one another (as opposed to treating every new problem as something totally unique). I recently heard a high-profile professor in Computer Science claim that reduction is one of only two truly new ideas our discipline has ever contributed to science (though she called this idea “hierarchy”, with the other idea being “abstraction”).

A natural question to ask next would be if all problems can be tackled with reduction. Unfortunately, in practice, finding the right translation between a pair of problems (Step 1, above) can be prohibitively difficult. Reduction is easiest when the two problems seem to have an obvious relationship we can exploit, which brings us to the Molecube and the Rubik’s cube.

A Sudoku-Like Transformation

It’s difficult to overstate how much of the Molecube’s solution is given away in its advertising as “Sudoku + Rubik’s cube”. My solution will treat this equation quite literally, starting with a transformation that relies on a Sudoku puzzle. I found this transformation by asking two simple questions:

How are the Molecube and the Rubik’s cube similar?

They’re both 3x3x3 cubes, meaning they both have 6 faces, 8 corners, and 12 edges. This totals 26 balls (on the Molecube) or blocks (on the Rubik’s cube).
Their physical mechanics (spinning, twisting, etc.) are identical.
Their goals are, in a way, also identical: from a shuffled configuration, reach a goal configuration.

How are the Molecube and the Rubik’s cube different?

Their goal configurations are different: the Molecube wants one ball of each color on each face, while the Rubik’s cube wants each face to be all the same color.
There are nine colors on the Molecube, but only six on the Rubik’s cube.
A block on the Rubik’s cube has 1–3 colors (one for each face it touches), while a ball on the Molecube is the same color on all “sides”.

The similarities hint at a solution: though the goal configurations are different, the cubes' structures and mechanics are the same. So if I find a goal configuration for the Molecube, I can use the Rubik’s cube algorithm to handle all the tricky rearranging involved in actually getting there.

If that’s enough of a framework for you to attempt your own solution, feel free to download the worksheet I’ve created to help you visualize the Molecube as a Sudoku puzzle (with colors instead of numbers). You’ll want to stop reading here and come back once you’ve completed a goal configuration or if you’re stuck and need hints.

Speaking of hints, the best way to unlock this tricky Sudoku-like color puzzle (getting one color on each face) is to study the Molecube’s colors and structure. I asked myself the following questions (which culminated in the table at the top of the worksheet):

How does the Molecube fit nine colors on a cube with 26 balls?
How are the colors distributed over the different types of balls (centers, corners, and edges)?
Are there any patterns that appear when trying to place balls of a certain color so it appears on each face exactly once?

The answers to these questions are revealing. There are three balls of each color, with the important exception of Green, which only has two. Further, Green is the unique color that is on two corners. Red and Purple are each on three edges, and the remaining six colors (White, Black, Orange, Yellow, Light Blue, and Blue) are each on one center, one corner, and one edge. This information — after some careful thinking — reveals the patterns we need:

As in the Rubik’s cube, centers opposite one another are always opposite one another (i.e., Black is always opposite White, Orange is always opposite Yellow, and Blue is always opposite Light Blue).
The only way the two Green corners avoid being on the same face is if they’re opposite one another (e.g., upper-right-back and lower-left-front).
The only way the three Red (or Purple) edges avoid being on the same face is if a Red (or Purple) appears exactly once in each “middle band” (shown below, left). So each middle band contains exactly one Red and one Purple.
For any of the remaining colors, (e.g., Blue) there is a center of that color. This blocks the corner of that color from being in the same “layer”, so the corner must go in the layer opposite the center (shown below, right). Once the position of the corner is fixed, there is only one position the edge of that color can go.

Using these rules and some trial and error, I found the solution shown below, also detailed in the worksheet solution. (An interesting aside: I don’t know if this is the only solution, but any solution works for the reduction). To relate the Molecube solution to the Rubik’s cube solution, we simply treat each 3×3 face on the Molecube as a “color” on the Rubik’s cube. (For example, the Black ball at the top-left of the White-center face becomes the Red-White-Green block on the Rubik’s cube). This completes the transformation step of the reduction.

Rubik-ing the Molecube

With the difficult transformation step out of the way, the rest of the reduction is easy. You can solve any shuffled Molecube just like you would a Rubik’s cube (assuming you know how to do that), but instead of aiming to have faces with all the same color, you aim to build the goal configuration we got from the transformation (above, left). To make this easier for me to visualize, I made a 3D rendering of my solution (front view on the left, back view on the right).

I was pleasantly surprised at how much Rubik’s cube muscle memory I still had from speedcubing in junior high (though if you need a refresher, I found this tutorial helpful). Interestingly, some of the steps in the Rubik’s cube “algorithm” are unnecessary for the Molecube. Remember the earlier observation that the Molecube’s balls are each a single color while the Rubik’s cube blocks can have 1–3 colors each? This means that the Molecube doesn’t care if its balls are rotated “in place”, though this is a problem for the Rubik’s cube (see the example below). So any steps in the Rubik’s cube algorithm that are meant to fix things like this can be skipped entirely.

But Does It Work?

To show that the reduction approach not only works but is also reasonably fast, here’s me solving the Molecube in just under 2 minutes.

There are a lot of Rubik’s cube-inspired puzzles these days (for example, the Ghost Cube and the Pyraminx). But solving the Molecube by reduction makes me wonder just how many of these new puzzles share a similar relationship to the original Rubik’s cube. If these relationships exist, we’d find that these new puzzles aren’t really new at all; they’re just an old puzzle we know how to solve, but with new names and nice packaging.

Git Going With GitKraken

Tue, 22 Jan 2019 12:40:00 -0700

Our team over at the SOPS Lab has been writing a lot of code lately as part of an ongoing effort to make our AmoebotSim simulator publicly available through an open source release. There’s a lot of diversity in coding/software engineering experience among our team members — from finishing a first course in C++ to completing several internships in big tech — so I’ve been spending some time thinking about how to make on-boarding easier, forming new students into conceptual thinkers and proficient programmers as quickly as possible. This tutorial on the basics of Git is meant to help with that.

Necessary Disclaimers

We have to get two things out of the way up front. First, this is not really the “accessible to anyone, technical or not” kind of post that I usually aim for. While it is meant to be simpler than the average Git tutorial, it’s still going to talk about software skills that are, by nature, technical. Speaking of other Git tutorials: yes, I do know how many Git tutorials already exist. Many of them are ones I’ve learned from and am inspired by. Some are far more complete, more specific, more polished, and even more craftsy than what I intend to do here. The point of this tutorial is to distill all that wonderful material into something that gets students (and other newcomers) acquainted with basic Git concepts and comfortable with a great Git client all in one sitting.

As a last bit of housekeeping, I’d like to credit Rachel M. Carmena, whose methodology I’m following quite closely.

Git’s View of the World

Git sees a software project loosely like this:

Big picture: there’s the remote server that houses the full software project and all the changes that have been made to it so far, and then there’s your computer where you implement new features and code changes. Now, Git is usually used when writing software collaboratively, so while the above picture is all that you have to worry about, the real setting is more like this:

Hold Up, What’s Git?

Git is just a piece of software that’s openly available for anyone to use. (Aside: it’s not a company or something that’s sold commercially, though this is often confusing because of companies/services like GitHub and GitLab). The problem Git is trying to solve, informally, is to support many people editing the same set of files concurrently while causing as few conflicts and headaches as possible. You might recognize that Google Docs and Dropbox try to solve a similar problem, but with a different strategy that makes them poorly suited for software development. Imagine for a moment that you were trying to use Google Docs for writing real code. Say you’ve been up all night working on a cool new feature, tracking down all its subtle and frustrating bugs, and now you want to compile and test it one last time to make sure it’s all good to go.

But right as you go to compile, your teammate gets in there and starts writing some other code, which naturally isn’t complete yet and doesn’t build! What do you do? Do you hit them up on Slack and ask them to stop coding while you test your feature? (If so, that essentially means only one person can be working at a time). Do you just keep trying to compile over and over until you get lucky and it builds? (If problems arise in testing, you won’t be sure if it’s your code that’s causing issues or someone else’s). This is nightmarish and no one does this. (I hope).

Git is an example of distributed version control software, a type of software meant to make these kinds of situations much easier to handle by giving each user more control over their own version of the files and when to incorporate the changes made by other people. (For the record, there are other choices for distributed version control, but Git is by far the most popular).

Tools of the Trade

In Git, the remote repository contains the current version of the shared code. Remote repositories can be set up on any server (or even your own workstation), but most people prefer to use a service like GitHub, Bitbucket, or GitLab to host their projects for them, which makes life easier. Think of it like this: GitHub is to Git repositories as WordPress is to websites. You can certainly host your own website, but using a service like WordPress saves you the trouble of maintaining a web server yourself. Our team uses Bitbucket for our AmoebotSim project, so that’s what’ll be in the screenshots.

An additional way to simplify using Git is to get a nice Git client like GitKraken or GitHub Desktop instead of interfacing with Git on the command line (which many hardcore users will tell you is the only way to really learn Git). Using the website analogy again, Git clients are to Git repositories like themes and rich-text editors are to websites. Could you put a stellar website together writing your own HTML, CSS, and JavaScript? Sure. Would you learn a lot more about how websites work doing it this way? Of course. But it takes a lot longer, and there’s much more room to make mistakes. In general, Git clients make understanding your repository a breeze with nice graphical representations and controls. I’ll be using GitKraken here, and I highly recommend you do too!

Cloning a Repository

Getting a copy of a repository from a remote server onto your machine is called cloning a repository.

Cloning makes a copy of the remote repository to your local repository. This not only includes the most recent version of the files but also the entire version history (list of changes) for every file, who made those changes, when those changes were made, and all the different branches of those files that your collaborators may be working on (we’ll come back to branching in a future post). The clone operation also puts the most recent version of the files in your working directory, where you can open them up in your file system and start making changes.

This is pretty easy to do with GitKraken:

And it’s even easier if you’ve already signed into your hosting platform (e.g., Bitbucket) in GitKraken:

Making and Submitting Changes

Now that the code is in my working directory, I can make my edits. From Git’s perspective, changes can either be tracked, meaning Git knows about them, or untracked, meaning the changes are in new files that haven’t been added to Git yet. Either way, I can add all the changes I’ve made to Git’s staging area in a process called staging:

To illustrate this, I’ll be adding license and copyright information to AmoebotSim (a very important part of going open source). I’ll be making these edits in three parts: (1) adding a LICENSE file, (2) adding a copyright notice to our main.cpp file, and (3) adding an abbreviated copyright notice to the other source files. Adding the LICENSE file will initially be an untracked change (it’s a new file), while the other changes that edit existing files will be tracked.

Now that the changes are staged, we can commit them to our local repository. A commit is essentially a batch of changes with a description known as a commit message. In general, a commit message should clearly and concisely describe the changes its commit contains (see this post for best practices). Once that message is done, we can commit, adding our changes to the version history.

This is, per usual, easy to do and visualize in GitKraken:

But committing only puts our changes in the local repository (shown by the little computer icon in GitKraken), not the remote repository where everyone else can see them (shown by the profile picture of the repository owner). Updating the remote repository with new commits from our local repository is called pushing.

Once commits have been pushed, they’re out there for other repository members to see and use. Be sure that your code builds and is bug-free before you commit and push; otherwise, you’ll break everyone else’s builds and get a lot of angry messages asking you to fix your issues quickly! (There are ways to mitigate these kinds of problems, like branch/fork-based workflows with approval processes, but I’m saving those more advanced topics for a future post).

Getting Other People’s Changes

Say that you were offline for a couple hours (or days…) and are just returning to your project. Your teammates may have committed and pushed code while you were away, and you want to get all their changes. Git gives you two ways to do this: fetch and pull.

Fetching retrieves all the new updates (commits, files, etc.) from the remote repository and copies them to your local repository. These new updates exist separately from the rest of your work, allowing you to look into them independently from any changes you’ve made locally. If you want your team’s updates to be integrated with your local changes, you’ll need to merge them in.

This can potentially cause merge conflicts if both you and your teammates' commits changed the same lines of code. (Although, to be honest, Git can get confused and think all kinds of things are “conflicts” even when they’re not, so watch out for that). Thankfully, GitKraken has a slick tool for helping you fix your merge conflicts (this was, by far, the #1 reason our team recently switched to GitKraken from Sourcetree):

Pulling simply combines fetching and merging into one step. It retrieves all the new updates from the remote repository and automatically tries to merge them into your local repository, possibly triggering merge conflicts for you to resolve along the way.

In GitKraken, both fetching and pulling can be performed using the top toolbar. The following example shows a pull, though you can see for a brief moment how it first fetches the new commit before merging it in.

Git Out There

I’ve covered the rudimentary operations of Git and how to do them in GitKraken, but there’s much more to learn! In a future post I hope to cover branch/fork-based workflows, pull requests, and rebasing, all of which can play a role in using Git for larger projects.

As always, I welcome your feedback and questions. Happy coding!