It turns out that Google’s generous supply of free snacks to employees does more than just keep us fat and happy, my efforts to keep my snack intake down led to some interesting math too. In this post I’ll have a bit of fun with Gray code, prove wikipedia wrong (shock!), and get healthier by eating fewer snacks.

It recently occurred to me that my snack counting system was in unary: one piece of sticky tack for one snack. As a self-respecting computer scientist obviously I find this unacceptable – unary is okay for some very limited uses but binary should really always be your first choice. Clearly I had to change to a binary system.

The problem with standard binary numbers though is that I don’t want to have to move to many dots around. It sucks when I’m having my fourth snack of the week that I have to move all 3 dots to go from 011 to 100. Luckily there is a solution to this: Gray code, which allows you to count as efficiently as normal binary but only flips one bit at a time.

To use Gray code though I needed an easy way to count from one number to the next. It’s fine to know that I only need to flip one bit but I also need to know which one to flip. Skimming the wikipedia page I found this recipe for counting:

[…] at step

ifind the bit position of the least significant ‘1’ in the binary representation ofi– flip the bit at that position in the previous code to get the next code.

This is actually incorrect (more on that below) but I didn’t know that when I first read it. I just though “that sounds like a lot of work, surely it doesn’t have to be that difficult”. And it doesn’t if you look at how Gray code^{1} is constructed.

Gray code is constructed recursively. Given the sequence of Gray codes that count from 0 to *n*, for instance here are the values that count from 0 to 3:

00 01 11 10

you construct the set of numbers counting from 0 to 2*n* by adding a zero in front of the previous sequence, using that to count up to *n*, and replacing the 0 with a 1 and counting the previous sequence backwards to 0:

000001011010110111101100

This is a really neat construction and makes it easy to prove inductively that they have some of their nice properties: that you always change exactly one bit, that you never hit the same value twice, etc.

This construction also means you can increment a Gray coded number recursively, using this procedure:

- If the first digit is 0 and the remaining digits can be incremented, increment them.
- If the first digit is 0 and the remaining digits are already at their largest possible value, flip the first digit.
- If the first digit is 1 decrement the remaining digits.

The procedure for decrementing is the same, just inversed. This may sound complicated but can be phrased differently in a way that makes it easier to use in practice.

- You want to flip exactly one bit. Initially you want to flip a bit
*up*, that is, from 0 to 1. - You start from the far left, going right, and you must flip the least significant bit that can be flipped the way you want. You can’t flip a 0-bit
*down*since it’s already down, and you can’t flip a 1-bit*up*. - When you meet a 1 you change your mind about which way you want to flip, starting at the next bit. If you wanted to flip
*up*before, going forward you’ll want to flip*down*and vice versa. But only from the next bit.

I call this the flip-flop^{2} algorithm because you keep changing your mind about which way you want to flip the bit. Here’s an example of how it works. Say you want to increment this Gray coded number (it’s happens to be 115 but the concrete value is irrelevant):

01001010

You start out wanting to flip a bit *up*. The first bit is 0 so you can *up* it, which makes it a candidate for the bit to flip. We’ll mark it like this:

01001010

↑

The arrow goes up because we want to flip the bit *up*, and it’s green because it’s possible to flip it. Moving left, we also want to flip the next bit *up* but it’s already a 1 so we can’t and we make that one red.

01001010

↑↑

Moving left again, since the last bit we saw was a 1 we now change our minds and want to flip a bit *down*. The next two bits are both 0 so we can’t *down* those and mark them red too:

01001010

↑↑↓↓

The next bit is a 1 which we can *down*,

01001010

↑↑↓↓↓

and as usual we change our mind and now want to *up*. The next bit is a 0 which we can *up*

01001010

↑↑↓↓↓↑

And so on: the next bit we can’t *up* and the last bit we can’t *down *so both become red. The least significant bit we could flip the way we’d want is the third so that’s the one we’ll flip. The end result is this:

01001010 → 01001

110

↑↑↓↓↓↑↑↓

In practice it’s easy to do. You just scan the number from left to right, keeping track of operation you currently want to do and what the last position was where you could do an operation. Here’s a sequence of the Gray numbers from 115 to 122 with the procedure arrows like above; the bold digit is the one that was changed in the previous step:

01001010 → 01001**1**10 → 0100111**1** → 010011**0**1 →

↑↑↓↓↓↑↑↓ ↑↑↓↓↓↑↓↑ ↑↑↓↓↓↑↓↑ ↑↑↓↓↓↑↓↓

**0**→ 0100

**0**100 → 0100010

**1**→ 010001

**1**1

↑↑↓↓↓↑↓↓ ↑↑↓↓↓↓↑↑ ↑↑↓↓↓↓↑↑ ↑↑↓↓↓↓↑↓

Besides being a neat way to increment a Gray code the flip-flip algorithm has a few interesting quirks that are worth taking a closer look at. One thing you may have noticed is that each arrow in the diagrams have two binary properties: they each have a direction, up or down, and they each have a color, red or green. If you read these properties as bits they form two different numbers: the direction value where up is 0 and down is 1, and the color value where green is 0 and red is 1. Here is an example:

01001010 ** ** Gray code

↑↑↓↓↓↑↑↓

01110011 **115** Color value

00111001 **57** Direction value

If you think the color value, 115, looks familiar that’s because is is: it’s the binary representation of the Gray code. I found that pretty surprising when I noticed it. If you look at the color and direction values next to each other it’s also clear that the direction is actually the color right-shifted once. Here are the the color and direction values spelled out for the sequence above:

0100101**0** → 01001**1**10 → 0100111**1** → 010011**0**1 →

↑↑↓↓↓↑↑↓ ↑↑↓↓↓↑↓↑ ↑↑↓↓↓↑↓↑ ↑↑↓↓↓↑↓↓

01110011 01110100 01110101 01110110

00111001 00111010 00111010 00111011

**0**→ 0100

**0**100 → 0100010

**1**→ 010001

**1**1

↑↑↓↓↓↑↓↓ ↑↑↓↓↓↓↑↑ ↑↑↓↓↓↓↑↑ ↑↑↓↓↓↓↑↓

01110111 01111000 01111001 01111010

00111011 00111100 00111100 00111101

The intuitive reason for this becomes clearer if you interpret the procedure slightly differently. In the original phrasing you want to either change a `0`

to `1`

or a `1`

to `0`

, and you keep changing your mind about which you want to do. An alternative view is to say that you always want to make a 0 into a 1, but you change your mind about what is `0`

and what is `1`

. After a `1`

you now interpret a `0`

in the input as a `1`

, and vice versa. That way, in the cases where you can make the change you want, that is where the arrow is green, the bit must have been what you considered `0`

. And in the cases where the arrow is red the bit must have been what you considered `1`

at that point.

The view of flipping the interpretation of bits actually matches the way Gray code is constructed. To see this consider how you increment from 7 to 8 in Gray and standard binary. With standard binary you go from `0111`

to `1000`

, flipping all four bits. In Gray you go from `0100`

to `1100`

which is in some sense equivalent except that when you flip the highest bit you don’t have to explicitly also flip the lower bits because they are changed implicitly by changing your interpretation of `0`

and `1`

. Viewing the numbers and the algorithm this way makes it easier to understand intuitively that the bits where you can make the change you want must correspond to a `0`

in the binary representation and the bits where you can’t must correspond to a `1`

. Under this view the direction value tracks your view: if a direction bit is `0`

you view the bits normally, if it is `1`

you view them in inverse.

But wait, there’s more. The simplest way to Gray encode a binary number *n* is using xor:

intgray(intn) {

returnn ^ (n >> 1);

}

As we saw before the color value above is *n* and the direction is *n* right-shifted once. So in fact if you xor together the color and direction values you get the value you started with. And if you check with the examples above that is indeed the case. Intuitively, since the direction value determined how view view the bits, if there is a `0`

in the direction value the corresponding bit in the Gray value is the same as in the binary value. If the direction value has a `1`

you have to flip the bit in the Gray code to get the binary value. This is exactly how xor works, so xoring the direction value and the Gray value will give you the binary value. And, since xor is associative, xoring the direction and the binary value gives you the Gray value.

There is one point left to revisit which is the recipe given in the wikipedia article for incrementing a Grey code. Here it is again:

[…] at step

ifind the bit position of the least significant ‘1’ in the binary representation ofi– flip the bit at that position in the previous code to get the next code.

We can now tie this together with the flip-flop algorithm. Since the standard representation of *i* is the same as the color value, what this is saying is: find the least significant 1-bit in the color value, which is the least significant red arrow, and flip it. This seems wrong – surely you’re supposed to flip the least significant green arrow? Let’s try their algorithm.

Take a random number, say the Gray code for 4, 110. The binary representation of 4 is 100. The least significant (and only) 1 is in the most significant bit position. Flipping that in the Gray code gives you 010. This is actually the code for 3. So what seemed wrong intuitively, flipping the red arrow, was indeed wrong.

Instead what the flip-flop algorithm suggests is to flip the least significant green arrow, or 0-bit in the standard representation. Let’s try that. The least significant 0 in 100 is at the least significant bit position. Flipping that in the Gray code gives 111, which is indeed the code for 5. So it works in the example, and it works in general. Someone should probably fix that wikipedia article.

^{1}: Technically there’s more than one encoding that can be called Gray code but people usually mean binary-reflected Gray code and that’s what I mean too.

^{2}: I have no doubt this algorithm is well known so the fact that I’m naming it doesn’t mean I’m claiming to have invented something new – it’s just convenient to have a name for it

There’s either a hidden joke about endianness or you have changed your mind about what is left and what is right 😉

Gah, my left-right confusion (which is a real thing) has struck again. I’ve fixed it to the best of my ability.