Blog | Mohammad Moshtaghi

Elegant Derivatives of Large Products

Tue, 30 Nov 2021 11:57:40 -0700

An ongoing research project on modeling computer security has thrown me back into calculus for the first time since my undergraduate differential equations course in 2014, which as an aside was the only college course that forced me to buy the professor’s custom textbook just to get access to homework problems. (I’m still mad about that.) Anyway, my research led me to take the derivative of an expression of the form:

$$\prod_{i=1}^n f_i(x)$$

For the uninitiated, $\prod$ is a mathematical symbol meaning “product” (and is analogous to the $\sum$ symbol meaning “sum”). It says to look at each $f_i$ term as $i$ goes from $1, 2, \ldots, n$ and multiply them all together:

$$\prod_{i=1}^n f_i(x) = f_1(x) \times f_2(x) \times \cdots \times f_n(x)$$

Taking this derivative is something high-school me was much better prepared for than current postdoc me, but after some head scratching I found the elegant solution:

$$\frac{d}{dx} \prod_{i=1}^n f_i(x) = \prod_{i=1}^n f_i(x) \cdot \sum_{i=1}^n \frac{f_i'(x)}{f_i(x)}$$

As is common in mathematics, there’s a direct but tedious way to get this answer and another more elegant way to get the same thing. I’m not the first to derive this solution, but I’m writing it up for posterity because I will inevitably forget this trick in a few days. A PDF of the two derivations without all the handholding I’m about to do is available here.

Method 1: Product Rule

I had to sweep away years of mental cobwebs to remember the product rule for derivatives. My expression is a product, after all, so why not start there? The product rule states:

$$\frac{d}{dx}(u \cdot v) = u' \cdot v + u \cdot v'$$

This works for the product of two terms, but $\prod_{i=1}^n f_i(x)$ has $n$ terms. Let’s try peeling off terms one-by-one, starting with $f_1(x)$, and then applying the product rule.

$$\begin{align*} \frac{d}{dx} \prod_{i=1}^n f_i(x) &= \frac{d}{dx} \left(f_1(x) \cdot \prod_{i=2}^n f_i(x)\right) \\ &= f_1'(x) \cdot \prod_{i=2}^n f_i(x) + f_1(x) \cdot \frac{d}{dx} \left(\prod_{i=2}^n f_i(x)\right) \end{align*}$$

That’s progress, but now we have to repeat the process to deal with the $\frac{d}{dx} \left(\prod_{i=2}^n f_i(x)\right)$ term, peeling off $f_2(x)$ and applying the product rule again:

$$\begin{align*} \frac{d}{dx} \prod_{i=1}^n f_i(x) &= f_1'(x) \cdot \prod_{i=2}^n f_i(x) + f_1(x) \cdot \frac{d}{dx} \left(\prod_{i=2}^n f_i(x)\right) \\ &= f_1'(x) \cdot \prod_{i=2}^n f_i(x) + f_1(x) \\ &\quad \cdot \left(f_2'(x) \cdot \prod_{i=3}^n f_i(x) + f_2(x) \cdot \frac{d}{dx} \left(\prod_{i=3}^n f_i(x)\right)\right) \end{align*}$$

This expression’s going to have more layers than an ogre! If we were to do the peel-and-product rule strategy $n-1$ times, we would arrive at:

$$\begin{align*} \frac{d}{dx} \prod_{i=1}^n f_i(x) &= f_1'(x) \cdot \prod_{i=2}^n f_i(x) + f_1(x) \\ &\quad \cdot \left(f_2'(x) \cdot \prod_{i=3}^n f_i(x) + f_2(x) \right. \\ &\quad \cdot \left(f_3'(x) \cdot \prod_{i=4}^n f_i(x) + f_3(x) \cdots + f_{n-2}(x) \right. \\ &\quad \left. \left. \cdot \left(f_{n-1}'(x) \cdot f_n(x) + f_n'(x) \cdot f_{n-1}(x)\right) \cdots \right) \right) \end{align*}$$

Do you see the pattern? If we distribute the $f_i(x)$ terms at the end of each of the lines above into the parentheses that immediately follow,

$$\begin{align*} \frac{d}{dx} \prod_{i=1}^n f_i(x) &= f_1'(x) \cdot \prod_{i=2}^n f_i(x) + f_2'(x) \cdot f_1(x) \cdot \prod_{i=3}^n f_i(x) \\ &\quad + f_3'(x) \cdot f_1(x) \cdot f_2(x) \cdot \prod_{i=4}^n f_i(x) \\ &\quad + f_{n-1}'(x) \cdot f_1(x) \cdots f_{n-2}(x) \cdot f_n(x) \\ &\quad + f_n'(x) \cdot f_1(x) \cdots f_{n-1}(x) \end{align*}$$

We’re adding up a bunch of terms, each of which is a derivative $f_i'(x)$ multiplied by all the other $f_j(x)$’s, where $j \neq i$. Landing this messy, notation-heavy plane, we can rewrite this long sum as

$$\frac{d}{dx} \prod_{i=1}^n f_i(x) = \sum_{i=1}^n f_i'(x) \cdot \frac{\prod_{j=1}^n f_j(x)}{f_i(x)} = \prod_{i=1}^n f_i(x) \cdot \sum_{i=1}^n \frac{f_i'(x)}{f_i(x)},$$

which is the solution we came for.

Method 2: Leveraging Logarithms

Mathematicians crave elegance, and Method 1 wasn’t that. We had to keep keen eyes out for patterns as they emerged and carefully distribute/rearrange many terms to get the solution. This second method will be much cleaner, but as many clever methods do, it begins with an unintuitive step.

Let $F(x) = \prod_{i=1}^n f_i(x)$. Taking the natural logarithm of both sides,

$$\ln(F(x)) = \ln\left(\prod_{i=1}^n f_i(x)\right) = \sum_{i=1}^n \ln(f_i(x)),$$

where the last equality follows from the fact that the logarithm of a product is equal to the sum of logarithms. The derivative of the natural logarithm is:

$$\frac{d}{dx}\ln(x) = \frac{1}{x}$$

Using chain rule to take the derivative of both sides of the above equality,

$$\begin{align*} \frac{d}{dx}\ln(F(x)) &= \frac{d}{dx}\sum_{i=1}^n \ln(f_i(x)) \\ \frac{1}{F(x)} \cdot \frac{dF}{dx} &= \sum_{i=1}^n \frac{1}{f_i(x)} \cdot f_i'(x) \\ \frac{dF}{dx} &= F(x) \cdot \sum_{i=1}^n \frac{f_i'(x)}{f_i(x)} \end{align*}$$

If we plug $F(x) = \prod_{i=1}^n f_i(x)$ back in, out pops the solution:

$$\frac{d}{dx} \prod_{i=1}^n f_i(x) = \prod_{i=1}^n f_i(x) \cdot \sum_{i=1}^n \frac{f_i'(x)}{f_i(x)}$$

Concluding Thoughts

Having initially stumbled upon Method 1, I was surprised that this derivative came out so beautifully in the end. Credit where it’s due: I adapted the elegant Method 2 from this post regarding infinite products. I have some technical notes at the end of the linked PDF about when Method 2 breaks down, though I believe Method 1 does not have any of these problems.

Hopefully this was fun (and if it wasn’t, I doubt you read this far 😉). This is one of many examples in mathematics of finding multiple solutions to the same problem and learning something different each time. Next time you emerge victorious from a tedious derivation, see if you can find a clever alternative!

Pool Testing is k-ary Search for COVID-19

Thu, 09 Jul 2020 14:04:44 -0700

I’ve seen a handful of articles in the last week about pool testing and sample pooling for COVID-19. The gist of this technique is simple: to make our limited supply of test kits (reagents) stretch farther, mix several people’s samples together and then test the mixture for COVID-19. Ideally, if the test comes back negative, everyone in that “sample pool” could be declared COVID-free using just one test. Otherwise, if the mixture comes back positive, then additional tests are needed to find the individual positive samples.

I’m far from a public health and epidemiology expert, but as an enthusiastic computer scientist I can’t help but see binary search (or more generally, $k$-ary search) all over this pool testing technique. My goal in this post is to draw out this connection, illustrating why the efficiency of $k$-ary search (and of pool testing, by extension) is so attractive. I’ll also do some crude math to explore what happens to pool testing if there are too many infections in the population and how many tests it could actually save.

If you’re not interested in any of that but want to know more about pool testing, NPR has a short primer and the FDA has put out a statement on the topic. On the other hand, if you’re interested in more serious research on the topic, this footnote¹ is for you.

Finding Things Fast

In a search problem, the goal is to find a specific item $x^*$ amidst a whole bunch of possibilities $(x_1, x_2, \ldots, x_n)$. It’s like Where’s Waldo if Waldo were $x^*$ and each $x_i$ was a person on the page. Or, perhaps more practically, it’s the way you give your favorite maps app a specific address $x^*$ and it has to find that place’s data (latitude/longitude, reviews, etc.) amongst all possible places $x_i$ in its gigantic database.

A not-so-great approach to playing Where’s Waldo is to make a list of every person on the page and check them one-by-one to see if they’re Waldo. (This is, perhaps, an entertaining way to play since you get to appreciate all the fun and ridiculous details, but we’re going for efficiency here). In computer science, we call this strategy — or “algorithm” — brute force search: when all else fails, just try everything. How bad can this be? Well, in the worst case Waldo might be the very last person in our list, so we would have had to check all $n$ people before we found him. So, knowing that the least clever search strategy makes us try $n$ times before we find Waldo, can we do better?

Imagine that you have a friend who already knows where Waldo is and has agreed to help you out by telling you which half of the page he’s on (left or right). Now you only have to search half of the possibilities, or roughly $n/2$ people. Say your friend’s really helpful, and they’ll let you do this as many times as you want: they’ll keep telling you which half of the remaining section Waldo’s in until you find him. So at first you have $n$ people to look through, then after your friend helps once you have $n/2$, and after helping again you have $n/4$, and then $n/8$, and so on. In general, if your friend has helped you $i$ times, then you only have $n/(2^i)$ people to look through. Doing a little algebra, after your friend has helped you $\log_2(n)$ times, you only have $n/(2^{\log_2(n)}) = n/n = 1$ person left, and that person is Waldo. This strategy is binary search: “binary” because your friend splits the possibilities in two each time they help.

It may have been a while since you’ve brushed up on your logarithms, so let’s look at some numbers to get a sense of how fast this is. An average Where’s Waldo puzzle has roughly $n = 500$ people on it. So, if we were to use brute force search, we’d be looking through all $n = 500$ people. However, if we had our helpful friend to do binary search with us, we’d only need to ask their help $\log_2(500) \approx 9$ times before we found Waldo! Not bad, hey?

The key to binary search is in throwing away whole chunks of possibilities all at once, rapidly narrowing our search field. $k$-ary search is just a generalization, where instead of splitting the possibilities in half each time, we split them into $k$ equal parts. We then keep the $n/k$-sized section containing our target and repeat, requiring a total of $\log_k(n)$ search operations to find our target (which is even faster than binary search!). Before we call it quits with Waldo and get back to pool testing, it’s worth pointing out that there are plenty of ways to make searching even faster (especially with parallel algorithms). There are even search algorithms specifically for finding Waldo, if that’s your jam.

Pool Testing, Meet k-ary Search

Shifting our perspective on testing from personal experience (“Have I contracted COVID-19?") to the population level (“Who in our communities are positive?"), we can frame testing as a search problem. Among all individuals $(x_1, x_2, \ldots, x_n)$, we want to find those $x_i$’s that are positive for COVID-19 so they can isolate and get timely medical care. In this setting, brute force search would be individually testing every single person — and that’s way more tests than we have. The current US strategy of only testing symptomatic cases isn’t more “efficient” than brute force, it’s just brute force search on a (hopefully) small subset of the total population.

Pool testing, on the other hand, is similar to $k$-ary search. Just like our helpful friend telling us which half of the page Waldo isn’t on, a single pool test ideally shows us a whole group of people that we can declare COVID-19 negative; in our search for positive cases, we can look elsewhere.

Consider the situation depicted above, with $128$ total individuals needing tests but only $4$ of them COVID-19 positive (shown in red). If we tested all $128$ people individually (brute force), we would need $128$ tests. But suppose we could reliably test pools of up to $16$ people at once, as shown in the first row. Only three of the $128/16 = 8$ pool tests would come back positive, allowing us to immediately rule out $5 \times 16 = 80$ negative individuals. For the three positive pools, we need to do additional tests to find the positive cases. This could be done by individually testing everyone in the positive pools² — effectively using smaller brute force — requiring $3 \times 16 = 48$ additional tests. Alternatively (assuming we had enough samples), we could do pool testing again, this time on smaller pools.³ So long as there aren’t too many positive samples (something we’ll revisit shortly), this will help us save on tests: in the picture, we only end up needing $30$ additional tests to handle the $48$ individuals in positive pools. The table below compares the number of tests used by each testing strategy in this example, along with the number of samples per person required.

Testing Strategy	Tests Used	Tests Saved	Samples per Person
Individual (brute force)	$128$	$0\%$	$1$
Pool Testing (one round)	$56$	$56\%$	$1$
Pool Testing (repeated)	$38$	$70\%$	$> 1$

What Can Go Wrong?

At least a few serious things:

Added logistical complications for labs, including tracking which individuals' samples are in which pools, added mixing steps, etc.
The possibility of larger false-negative rates (i.e., testing negative when the sample was, in fact, positive) due to samples getting diluted when they’re mixed into pools.⁴
A loss of efficiency when there are too many positive samples.

For the rest of this post, I’m going to focus on that last problem. Pool testing’s strength lies in its ability to rule out large groups of negative cases at once, as we saw in the example. But with too many positive cases, the likelihood of pools testing positive becomes much higher, requiring a greater number of subsequent tests. At what point does pool testing end up using more tests than if we just tested everyone individually?

Instead of repeated pool testing (like in our example above), consider the more practical protocol of doing only one round of pool testing and then testing all samples in positive pools individually. If we have $n$ total samples, our pool size is $p$, and $x$ pool tests come back positive, then we will use a total of $n/p + xp$ tests: $n/p$ pool and $xp$ individual. Since we’d use $n$ tests doing brute force, pool testing only saves us tests if $n/p + xp < n$, or equivalently, if: $$x < (n/p)(1 - 1/p)$$

To connect the number of positive pools $x$ we’ll have based on how many positive cases are in the population, let $r$ be the probability that any given sample is COVID-19 positive. The probability that a pool of size $p$ contains a positive sample is $1 - (1 - r)^p$. There are $n/p$ total pools, so the expected (average) number of positive pools is: $$E[x] = (n/p)(1 - (1 - r)^p)$$ Therefore, we save on tests using pool testing in expectation if: $$\begin{align*} (n/p)(1 - (1 - r)^p) &< (n/p)(1 - 1/p) \\ r &< 1 - p^{-1/p} \end{align*}$$

The above graph plots this efficient region. The x-axis is the pool size $p$ and the y-axis is the infection rate $r$. Any point in the blue region represents a $(p,r)$ pair for which pool testing uses less tests than brute force in expectation. For example, with a pool size of $p = 16$, our crude math suggests that pool testing is more efficient for infection rates up to, coincidentally, $r \approx 16\%$. This would be a terrifyingly high infection rate (at the time of this writing, the CDC reports a $\approx 1\%$ positive case rate in the US), so it seems that in realistic settings even one round of pool testing would save a lot of tests.

Taking Our Savings to the Bank

To recap, we’ve seen how pool testing is related to $k$-ary search, how both of these techniques leverage the ability to rule out large groups of possibilities to narrow things down quickly, and how pool testing will save us tests so long as the infection rate is low enough. The last thing to nail down is how many tests are actually saved. From our work above, we know that the expected number of tests saved using one round of pool testing is: $$\begin{align*} E[\text{# tests saved}] &= \text{# tests for brute force} - E[\text{# tests for pool testing}] \\ &= n - (n/p + E[\text{# positive pools}] \cdot p) \\ &= n - n/p - (n/p)(1 - (1-r)^p)p \\ &= n(-1/p + (1-r)^p) \end{align*}$$ The fraction of tests saved is just the number of tests saved divided by $n$, so a single round of pool testing in pools of size $p$ uses a $(1-r)^p - 1/p$ fraction less tests. The following plot shows this equation for different pool sizes $p$ as a function of the infection rate $r$.

This shows that larger pool sizes have the potential for saving more tests, but also degrade in their efficiency more rapidly as the infection rate $r$ grows. Eventually, if the infection rate becomes too large, all four curves become negative and pool testing ends up using more tests than brute force. This corresponds to leaving the efficient region shown in the previous graph. If you’re having a hard time interpreting these curves, the following table compares pool testing with $p = 4$ (blue) and $p = 16$ (green).

Pool Size	Tests Saved at $r = 1\%$	Tests Saved at $r = 5\%$	Infection Rate for No Savings
$p = 4$	$71\%$	$56\%$	$r = 29\%$
$p = 16$	$79\%$	$38\%$	$r = 16\%$

The key takeaway is that from a purely test-savings perspective, pool testing does a remarkable job for any reasonable pool size. While it is true that pool testing can end up using more tests than traditional testing if the infection rate grows too large, my crude math suggests that the infection rate would need to be quite high ($r > 10\%$) before this inefficiency would be noticeable. At today’s US infection rate of $r \approx 1\%$, we could be $70\%$ more efficient with our limited supply of testing reagents, helping more people get tested more often. Perhaps if this technique were widely used, we would all be that much closer to safely getting on with our lives.

Cherif et al. 2020 detail a recent mathematical model for pool testing and Yelin et al. 2020 characterize its dilution and false-negative rates. The references in the Yelin paper also cover deeper mathematical analysis (e.g., Dorfman 1943) and how pool testing has been used to combat infectious disease in the past (e.g., for malaria in Taylor et al. 2010). ↩︎
From my brief sifting of the literature, practical implementations of pool testing only use one round of pool tests: roughly $65\%$ of each sample is used in a pool test, and the remaining $35\%$ is saved for an individual test in case the pool comes back positive. Repeated pool testing doesn’t seem to be used in practice, presumably because it would rely on collecting additional swab samples per person. ↩︎
I’ve depicted the subpool tests in a binary search kind of way where each positive pool is split in half and retested, but they could be broken into any number of groups. ↩︎
Yelin et al. 2020 estimate that the false-negative rates for pools as large as $16$ or $32$ is roughly $10\%$ based on their experiments. I chose not to do my speculative math for dilution and false-negative rates because I don’t understand how PCR tests actually work and don’t believe in blindly oversimplifying things for the sake of nice math. ↩︎

Announcing Reviews

Fri, 29 May 2020 14:07:51 -0700

I’m excited to announce that I’ve added art and entertainment reviews to the site. I’ve posted 28 reviews of books, movies, and video games so far; I will likely extend this to also include TV shows and music in the future. This post is a brief look at why I review things (it’s not for glorification of my own hot takes, I promise) and a bit about my experience with hacking the Hugo Academic theme to support reviews.

In case my philosophy behind reviews and hacking the site theme are less interesting to you than actual reviews, here are a few that I was particularly happy to rediscover:

Overcooked, a review from 2016 about the frantic cooperative cooking game.
Half the Sky, a review from 2017 about the book that played a pivotal role in my understanding and caring about the global state of women’s rights.
The Phantom Tollbooth, a review from 2019 about one of my favorite books.
Batman: Arkham City, a review from 2019 in which I question Batman’s approach to criminal justice and our assumptions about video game minions.

The Entertainment Backlog

Over the last decade, I’ve been iterating over ways to track my progress and remember my experiences with various books, movies, TV shows, music, and video games. It bothers me that I own more content than I have time to experience and that I often forget my key takeaways just months after finishing something. What came of my efforts was the entertainment backlog, an informal and messy system of spreadsheets, notes, and written reviews.

In concept, the backlog is simple: it’s a list of content (books, movies, music, games, etc.) organized by progression. When I’ve purchased something (or, in the streaming era, when I’m interested in it and have access to it), I add it to the backlog as “Owned.” When I start reading/watching/playing it, it becomes “In-Progress.” Once I’m done with it, it becomes “Completed.” With just these three stages, I’m able to keep track of what I’m engaging with and avoid forgetting about it and having to start over a year or more later. As a caveat, if ever something is boring me, I just drop it from the backlog altogether. The system is there to support me, not force me to complete uninteresting stuff.

Implementation of these three stages can come in a variety of formats. The gold standard would probably be some dedicated, slick piece of software. I’ve gotten by with a mix of spreadsheets, a Trello board (Owned/In-Progress/Completed are lists, and each item is a card), and an “art and entertainment journal” where I write about what I engage with daily. Regardless of how it’s implemented, the point is to not let things go stale.

The Role of Reviews

The fourth and final stage of the backlog is “Reviewed,” which is where “Completed” items go once I’ve written some thoughts down about them. Traditionally, my reviews have had a numerical rating and a written portion, though as I get older I find that my ratings are less useful to me than my reflections.

I write reviews for two reasons: to avoid forgetting my experiences and to combat entertainment consumerism with reflection. These goals work together. When entertainment is reduced to “empty calories” because I don’t spend any time reflecting on it, I’m always hungry for more. When I know I will invest thought and energy into my entertainment, I can be more selective about committing to higher quality experiences. In turn, I can take the time to listen to and be impacted by what these experiences have to say in their stories and art.

Rest and play are non-negotiables in my life, but taking time to reflect thoughtfully on what I’m engaging with helps me keep a healthy relationship with less intentional entertainment and make space for more challenging and impactful art and nonfiction.

Hacking the Academic Theme

This was my first real attempt at working with HTML, CSS, and JavaScript beyond some Codecademy lessons I did in undergrad, so building out reviews was an uphill climb, even when mostly working with preexisting structures provided by the Academic theme. No particular lesson learned is a big enough deal to write about, but I’m most proud of integrating third-party scripts progressbar.js and chroma.js to help with the animation and coloring of the numerical ratings at the end of each review.

This is just a screenshot, but the real ratings animate when they’re first loaded. The animation is usually done by the time you scroll down to the bottom where the ratings actually are, but refreshing the page will let you see it in action! It’s potentially possible to delay the animation until the ratings are scrolled into view, but my knowledge of jQuery is nonexistent so I’ll be leaving that as an improvement for another day.

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.

The Three Academics: A Joke

Tue, 30 Jul 2019 09:15:00 -0700

Mathematicians really care about correctness. We believe unspoken assumptions are dangerous. We think vague language is confusing, and saying more or less than we mean is grounds for misunderstanding. We want terms to be clearly defined, and for points to follow logically, like links in an unbreakable chain of truth. But sometimes people say things that are completely reasonable and yet we still feel the need to set them straight:

This is my first contribution to the world of webcomics, a medium I’ve long admired for being able to deliver witty, weird reflections on life in simple packages. Giving credit where it’s due, this “joke” is adapted from The Curious Case of the Dog in the Night-Time by Mark Haddon and the art style takes after poorlydrawnlines by Reza Farazmand. In living out generous making, this comic is available as a high resolution PNG or PDF for you to use as you’d like. (Just keep my authorship in the corner intact, please!)

And hey, to the economists out there: if you’ve got any good roasts of mathematicians, I’m all ears.

SureChoice: Making Informed Insurance Decisions

Sat, 29 Jun 2019 22:21:00 -0700

Health insurance is confusing. Last year, after Annie and I got married and she started a new job, she came home from orientation day with the book. The book of health insurance plans, complete with overcomplicated tables of costs and percentages, interspersed with pictures of smiling people. I assume they’re smiling either to make me — the daunted reader — feel assured, or because they know they’d be screwed in the U.S. without health insurance. But that’s another issue.

Choices, Choices

The problem with displaying a health insurance plan using many tables is that it’s very difficult to make comparisons between plans. One plan might be more costly than another in certain categories but not in others. One might have a low deductible while the other has a high co-pay. Yet a third plan might have a very middling premium and comes with a Flexible Savings Account. Even if I know what all these terms mean and how they interact with one another, it’s still hard to discern which would be best for our family’s specific health needs. And, to top it all off, I can’t know if I’m getting a good deal since insurance rates are negotiated between insurance companies and employers, and there’s very little info available online to compare with.

This, I think, is where uncertainty sets in and some word-of-mouth advice can end up replacing mathematical reasoning for some people. (Or, for those who grew up in the 2000s, maybe you have a vaguely negative feeling about HMOs because of Melman from Madagascar.) But Annie and I wanted grounded answers, so we went to our whiteboard, scribbled a ton of math and graphs, argued about said scribbles, eventually came to realize we agreed about everything we were arguing over (classic), and got to work.

Cutting Through the Jargon

A big part of this for me was simply understanding what all these health insurance words meant. Here’s what I learned (feel free to skip if you know this already).

A premium is a cost you pay every month just for being on insurance. Think of it like the cost of a Netflix subscription, but more expensive and way less entertaining.
A deductible is a set amount of medical costs that you are 100% responsible for. Insurance is only going to kick in and make things cheaper after you “meet” your deductible.
A copay (co-payment) is the percentage of medical costs you’re responsible for after your deductible is met.
An out-of-pocket maximum is the maximum amount of money you will be responsible to pay in a year.

Let’s work this as an example. Say I have Plan A, shown below.

	premium	deductible	copay	out-of-pocket maximum
Plan A	$200	$500	20%	$4,000

Say my plan starts in January, and the first three months go by without any doctor appointments, prescription refills, etc. By the time March has ended, I’ve paid $\$200 \times 3 = \$600$ in premiums. Then, in April, I get an infection and need to see my primary care physician. The doctor is charging me $\$75$ for the visit, and the medication they prescribed is another $\$75$. Because I haven’t met my deductible yet (premiums don’t count!), I have to pay the full $\$150$. I’ll also, of course, have to pay my April premium of $\$200$. (This whole healthcare thing is expensive, isn’t it?) Time goes on, and by October my family has paid $\$500$ out-of-pocket. But crisis strikes: I get in a car accident and break several bones. I’m rushed to the hospital via ambulance, and have to spend several days in the hospital getting stabilized and getting casts set. Our bill comes out to be $\$25000$. But because our copay has now kicked in, we’re only responsible for $20\% \times \$25000 = \$5000$, and we only have to pay $\$3500$ of the bill before we hit our $\$4000$ out-of-pocket maximum.

Whew.

A Piecewise Function

I made many simplifications to the healthcare system in my example above, but a year on health insurance can roughly be split into three stages: paying 100% of costs until meeting the deductible, paying only the copay percentage of costs after the deductible, and paying 0% of costs after hitting the out-of-pocket maximum. If we were to plot this with the x-axis being the total medical costs without insurance and the y-axis being the out-of-pocket costs with insurance, we’d end up with something that looks like:

Once Annie and I saw this, we realized we could plot all of our plan options onto one graph and immediately be able to see what would cost us the most depending on the medical costs we incurred. We only needed to add in the annual premium costs to see a decent approximation of everything we’d spend on health insurance in a year with each plan.

Building SureChoice

I quickly threw together some MATLAB code to compute and plot the piecewise cost function for each of our possible plans. What we found cut straight through the sales language in our plans booklet and made everything quite concrete: the best plan for us had everything to do with the medical costs we would have. Here’s an example plot:

Every line in the plot shows how expensive that plan would be if we had the total annual medical costs shown on the x-axis. The HMO plan (blue), for example, is almost always the most expensive plan (except for the $\$3000$–$\$9000$ range, where it’s better than the HDHP plan). If we knew we were going to have over $\$30000$ in costs, the HDHP plan is the best. If we were going to have under $\$5000$ in costs, everything but the HMO plan is roughly the same. The EPO plan basically wins out in all other cost ranges. All in all, this kind of visualization helped us to make the most cost-effective choice for our expected medical expenses.

I’ve recently cleaned up my code, ported it to Python, and put it up on GitHub for anyone to use (…assuming you know how to run Python code). Hopefully it can help you like it helped us, and if you have the skills to turn this into something easier to use (a web app, etc.) go for it! We might not be able to change these confusing systems, but we can at least make them easier to navigate.

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!

Oh, the Places You'll Go

Fri, 21 Dec 2018 12:15:00 -0700

As a PhD student, I get to travel quite a bit. In just the last two years, I’ve been to Atlanta (a few times, once as a visiting researcher to GaTech for 3 months), Austin, Vienna, Dagstuhl, and — most recently — Tokyo. I get to meet interesting researchers on every trip, whether it be during a conference coffee break (where “meeting” people occasionally feels like getting interrogated about research) or by running into each other while meandering through a national park.

These trips are largely work. I listen to talks on the latest research and imagine ways to connect them to my own. I introduce myself to more senior researchers (usually hesitantly) in the hopes that they’ll remember who I am once they’re through answering my questions. I stay up way too late the night before my talk polishing my slides to (what I hope is) perfection. I scribble all over whiteboards, drawing (mostly) intelligible pictures when working out new ideas with collaborators.

Need to update “slides” with a link to the talk I gave at WSSR.

But then there’s the beauty of getting to go to new places because I have to. As an introvert and someone who’s pretty happy being in one place, travel is definitely not an itch I need to scratch (to me, “wanderlust” often feels like a made up word fellow Millennials use to describe the need for jealousy-inducing Instagram content). But my PhD has helped me learn that there’s a lot out there to see and understand, and somehow the difference and uncertainty and novelty of it all makes me feel hope.

So, until we meet again, Tokyo.

On Your Marks, Get Set, Coat!

Mon, 11 Dec 2017 09:05:00 -0700

My first journal paper was published early last week, marking a milestone in the winding forest path that is my PhD. The paper has some nice ideas and results I’m proud of, but — regrettably — the writing style and level of mathematical rigor needed for publication can make it pretty hard to decipher for anyone not familiar with our niche of computer science. I’m of the opinion that ideas are only useful if people can understand them, so to that end I’m going to explain this paper in a way that’s a bit less formal and academic. With a little effort, I think we’ll both learn something new here. (And if it’s still all Greek to you, I’ll happily answer questions you leave in the comments).

The Nickel Version (TL;DR)

The paper (whose title is mathy and unimportant) is all about programming futuristic, sci-fi materials that don’t exist yet to coat other objects in even layers as (relatively) fast as possible.

The, Uh, Dollar(?) Version

Let’s take a look at the paper’s title (emphasis added): “On the Runtime of Universal Coating for Programmable Matter.”

Runtime is a word we use to talk about how fast an algorithm is. As in many other aspects of life, faster is better and more efficient. So this paper is about how fast “Universal Coating for Programmable Matter” is.

Programmable matter broadly describes any kind of physical material that can change itself as a reaction to what’s around it without human interaction. It’s a bit sci-fi, but imagine a future in which roads fill their own potholes and cracks after wear and tear, clothes heal themselves from fraying and holes, or artificial cells isolate and neutralize malignant tumors in the human body. It sounds crazy and is definitely out there, but that’s what we’re talking about here.

Universal Coating is the action we’re trying to do. In this context, we mean “coating” like a coat of paint; we want to cover something as evenly as possible. (Nobody likes a lumpy paint job). “Universal,” as a math word, means that a technique works in many/all cases. Here, we’re talking about a single approach to coating that works no matter what the object to be coated looks like. (Which is pretty cool).

So, all together, this paper is about analyzing the speed of a particular approach to using futuristic materials for coating any kind of object in nice, even layers. (Ok, so even the one sentence wrap up is a mouthful). Also, a big thank you to Annie Carson for the great illustrations!

So How Does It Work?

I’m really glad you asked. Actually, I’m really glad you’re still here after that heavy appetizer of an overview; hopefully it didn’t spoil your appetite before our main course, which starts right now! Take a look at a simulation of the Universal Coating algorithm over on our lab site, and keep it open for the rest of this section so you can refer back to it.

We need a bit of terminology before I explain what’s going on with all those dots and colors. There are two main “things” in this algorithm. Thing 1 is the object, which is the cluster of dots with black circles in the middle. We’re keeping things nice and simple in this example by making the object a hexagon, but it can be essentially any shape you want (“universal”, remember?). Thing 2 is the particle system, which are all the other dots that move around and change color. “Particle system” is just the term we use for the programmable matter stuff we talked about before: we’re trying to coat the object with these particles.

In really broad strokes, the algorithm can be broken down into four major steps:

Get all the particles oriented towards the object using something like follow-the-leader. In the simulation video (0:00–0:02), this is when they all turn yellow. If you start at any yellow particle and follow its pointer to the next particle and so on, you’ll always end up at the object.
Coat the object’s first layer. This happens insanely fast in the video (0:01–0:02) but there are actually a couple particles that turn red and fill in the few positions on the object’s first layer that weren’t already filled. You can see them if you pause the video and drag the slider back and forth around 0:01.
Decide on a position to be the start/end of each layer. Choosing this marker position plays a big role in helping the particles learn when one layer is finished so they can start forming the next one. In the video (0:02–0:07), this decision process is shown with the line segments around the object changing colors. At 0:07, the particle occupying the marker position turns a light grey color.
Coat the object in more layers one by one until all particles have been used. The video (0:08–0:20) shows this quite clearly, with finished particles turning green. The grey line of particles growing from the object towards the bottom are the particles from Step 3 which mark the start/end of each layer.

And that’s it! Perhaps as a point of pride, I have to mention that — although simple to describe — this algorithm is really involved. One of the main difficulties is that each particle runs this algorithm individually, so instead of Steps 1–4 happening nice and sequentially, they can actually all happen at once. And… yeah, it’s as chaotic as it sounds. The good news is that, in a previous paper, our group proved this algorithm always works, no matter what. Going forward, we’ll just take the fact that it works for granted.

(Quick) Get Your Coat!

I can’t remember how many times I got in the car to go somewhere as a kid only to be sent back inside to get a jacket. Mom never said the “quick” part, but it was definitely implied!

We’re going to shift our discussion to the real work of this new paper: proving that our Universal Coating algorithm runs reasonably fast. Let’s start with a motivating example for why you might do this kind of analysis:

Pretend there’s a secret technique for earning $1,000,000. Maybe it even comes with a guarantee that it will always work. We might get excited about something like that, or at least want to know more. But what if we found out that no one knew how long it would take to work? Or even worse, what if the fine print said it would take more days than the number of atoms in the universe? Well. We might still be waiting for our payout long after inflation turns a million dollars into pocket change, the cows come home, and the sun expands to consume the earth.

The lesson to be learned here: we need to know both that an algorithm works and that it won’t take a ridiculously long time. So how do we analyze the algorithm’s runtime? There’s often more than one way to crack that coconut, but the techniques can get pretty involved. Even getting a mastery over the most fundamental techniques can take the larger part of most undergraduate Computer Science (CS) programs. (Fun fact: this side of CS doesn’t even have to involve programming, contrary to the popular belief that CS people are a bunch of tech support code monkeys. Yes, I probably can fix your iPhone. No, I didn’t learn that in school.)

To explain both why analyzing our particular algorithm was nasty and how we ended up doing it, I’ll use a quick allegory. Imagine a race between two teams: Team Red and Team Blue. Team Red works like a machine: everyone comes to practice and trains hard, they perform well in events, and — most importantly — they run in perfect lock step, starting together and finishing together. Team Blue, on the other hand, is more about the individual effort. They also perform well in events, but have a mix of sprinters, endurance runners, runners who like to stop and smell the roses, and so on. Some of Team Blue’s runners end up finishing really fast, while others take longer.

Our particle systems are, essentially, Team Blue. We don’t make any assumptions about how fast each particle works relative to the others, and it’s entirely possible that a particle can suddenly go faster or slower than usual without following a pattern. This makes it hard to figure out when the last Blue runner (or particle) will cross the finish line. So, instead of directly analyzing our system (Team Blue), we proved two things:

Team Red — a simpler version of our particle systems where everyone progresses through the algorithm at the same rate — runs “fast”.
Team Blue (our particle system) always runs faster than Team Red.

Therefore, as a nice logical result, Team Blue also runs “fast”. In fact, it’s entirely possible it even runs really fast!

Good Job Out There, Get Some Water

As a recap, we have an algorithm for programmable matter which coats objects of all shapes and sizes. We showed that this algorithm always works in an older paper, and that it runs pretty fast in this new journal paper. This runtime analysis boiled down to showing that a simplified version of our particle system runs the algorithm quickly, and that the real particle system always runs it even faster. (For my CS people out there, we showed that the Universal Coating algorithm runs in $\mathcal{O}(n)$ asynchronous rounds with high probability, where $n$ is the number of particles in the system).

Thanks for reading, and feel free to comment with your thoughts, ideas, and questions!