## the message is the message

It’s been said by certain researchers that happenstance has played a role in many of their most exciting discoveries.

this is not one of those exciting discoveries. BUT it *is* happenstance… I’ve been off flying from Brooklyn to Brussels and then to Bristol — no, the letter ‘B’ is not the happenstance I speak of (what does that even mean? …Weirdo).

After a fuzzy day of being jet-lagged and sleeping through important Belgian meals and British moments (“Eee gad! You haven’t seen *The Hobbit* yet?! Crikey!), I eventually awoke in a bed quite foreign and promptly spent a good 10 minutes trying to find out what the time actually was.

My phone? Dead. My laptop? Dead. To add to my troubles, none of these things could get plugged in either because my sleep-addled brain would not find the 120 to 220 volt adapter hidden somewhere in my suitcase. And as a finishing touch, my brain’s internal clock was also, not surprisingly, dead.

So instead of getting out of the room and asking the British countryside what time it was, I decided to think about the following: Would it be possible to power a clock on the external top of my laptop? Ideally, I’d be able to glance at the closed laptop to see a dim digital readout that gave me enough information to read the time.

Sadly, the answer is: “No, probably not. I am pretty lousy at building tiny electronic devices. So… that’s that.”

Well, entry over, I guess. But not really, because here is where the happenstance comes in. I just finished Charles Seife’s brilliant book, “Decoding the Universe,” which led my aforementioned sleep-adled brain to a more interesting question: “How much information does one actually need to know what time it is?”

This is a deceivingly simple question, and thanks to Dr. Seife I was in the frame of mind to make an earnest attempt to tackle it.

So we have to ask: what are the simplest terms for defining the things we wish to communicate, i.e., information? In the classical (non-quantum) sense, we could answer: asking a question and getting an answer; setting up a series of if/then statements and having a value returned; devising a clever series of yes/no questions that will direct your inquiries to an answer.

The yes/no question schema, in fact, is quite ingenious. If I tell you I am thinking of an integer from 0 to 10,000, you could ask each number hoping to guess right, or you could narrow it down with a few questions: Is the number even? for example, in which you’ve instantly doubled your odds of knowing the number. In fact, with only 14 such questions, you are able to deduce with 100% certainty which number I was thinking of (it was 666, btw).

If you know anything about binary code, then you may recognize instantly what has happened here — for binary is really just a series of yes/no questions. In the binary number 010, the positions represented by each 0 or 1 stand for “2 to the power of” that 0 or 1’s position. Each position in this number is read from right to left (all binary code is read this way) and the right-most position stands for 2^{0} (which is equal to 1). The next position to the left stands for 2^{1}, or 2, and the third position over stands for 2^{2}, or 4.

The 1 in the second position is like a yes, and in this case, means that this position’s value (2^{1}, or 2) has a non-zero value. The other two positions are both 0’s, which is like a ‘no’, so their position values (2^{0} and 2^{2}) are both nil. Once each position is decoded, then all values are summed to find the decimal representation of our binary code. In this case, we have 0 + 2 + 0 = 2. The binary number 010 represents the decimal number 2.

As another example, if you add another position on to the left of the above binary code, you could generate the binary number 1010, which gives 10 (8 + 0 + 2 + 0).

Each position is called a bit, to that the binary number 010 has three ‘bits’ of information. The number 1010 has 4 bits. You may notice that the largest 3-bit number possible is 111, or 4 + 2 + 1 = 7. Similarly, the largest 4-bit number is 1111, or 8 + 4 + 2 + 1 = 15.

Binary code, just like a series of yes or no questions, is an exemplary way of transmitting information.

So. I want to use binary code to give encode all possible answers to the query, “what time is it?”

Above, when I wanted you to guess which number from 0 to 10,000 that I was thinking of, you may have wondered how I came to the conclusion that you would always get the correct number within 14 guesses. The clue to resolving this question is that each question should reduce the number of possible values for the integer in my brain by half. For example: Is the number less than 5,000? Yes? Is the number less than 7,500? And so on. This type of questioning splits the possible answers in half each time, giving us a binary field of possible answers with each question.

The question, reworded becomes: How many binary bits do you need to cover any possible number from 0 to 10,000?

Answer: any integer from 0 to 10,000 can be represented by a 14-bit binary number. A 13-digit number won’t go high enough and 15-bits is just overkill.

So how many numbers do I need to be able to represent the current time? In twenty four hours, there are 24 x 60 = 1440 minutes, each one is unique throughout the day, requiring 11 bits of information to represent time, to the minute (2^{11} = 2048 — which is the total number of representations, including zero, that we get with 11 bits). All those extra numbers that we *could* represent aren’t needed, but each and every of the eleven bits *are*; if you want to keep time in this manner).

Now we are really getting to the meat of this blog post, because now I want to figure out a way of using the least number of bits possible to convey what time it is.

Not surprisingly, if you decide to keep separate the hours and the minutes, you still need 11 bits (5 bits for the hour and 6 for the minutes).

So what other systems can we come up with?

The angle of a clock hand: not surprisingly, this is the same result — 11 bits. Even though the visual representation makes it easier to read for some (I’d guess harder for others — I’m not judging), you still need the same amount of information to resolve the time to within 6°, which represents one minute.

LED clock readout: Each digit placeholder can be represented using 7 diode bars of light (if you turn all seven on, you have an “8” if that helps you visualize it). The first digit in the hour only needs two possibilities: either one LED bar is lit, or none, so that’s one bit; but you’ll also have to add in a bit to tell you if it’s AM or PM. The second digit needs the full range of our 7-bit LED readout, so that makes 9 bits total. Already you can tell that we’re getting into trouble — but we shall persevere. The minutes need the full range, even though the number in the ten’s place only uses 0–6; the second figure also needs 7-bits.

Our final result here is a terrifying total of 23 bits of information to show the time on an LED display. However, we can try to change how many bits we need to display each number to help with the total. We should be able to easily represent the digits 0–9 with 4-bits of information. However, we’re right back where we started — back to a numeric representation of, um, numbers, so this does not help at all.

What about visual cues? I dunno, like a rooster crowing at dawn? Not very helpful if you’re traveling.

Or 3-d representations? Seriously, i don’t know what you’re going on about now.

Any new ideas I come up with seem to always take us back to the old 11 bits of data… so maybe we don’t need so much accuracy? After all, who cares if it’s 3:42 or 3:44? To find out the time in 5-minute increments, we’ll need 12 numbers for the minutes, 12 for the hours, and one extra to tell if it’s AM or PM. Our new total is 9 bits! Now we are cooking.

If we were to now implement the LED approach, we do see some real progress. The new minutes is comprised of the one’s place needing to only be one of two values: 0 or 5, so one bit. The ten’s place needs 3-bits (0–6), and the hour and AM/PM need 5 total. Still 9 bits. Hrumph.

What about just knowing the quarter hour? Now we’ll need 7 bits.

Every half hour? 6 bits.

Every hour — 5 bits.

We could forgo an AM/PM bit to get down to 4 bits, and to get down to 3 bits, you’d only get to know the time within a range of 2 hours or so.

A two bit clock could tell you which quarter of the day you were in, but seriously, that is a two-bit clock.

Now we’re losing some serious accuracy, so we should probably stop that silliness.

But it now occurs to me that, with a little planning, it may be possible to have one bit of information that can help me decide what time it is. With foresight and the tiniest bit (ha!) of reflection, the accuracy would even be quite acceptable. An alarm.

Oh, the alarm. It is such a tidy little machine. It asks my clock a question every minute. The alarm is persistent. The clock is patient. The alarm says, “Is it 7:36 AM yet?” and the clock answers, “No, not yet dummy.” But at some point (precisely 7:36 AM), the clock answers “Yes!” The alarm also responds with gusto and begins yelling at me and the clock and any passersby and probably my neighbors will get mad because of all the yelling.

The alarm is a useful tool. It calms me if I wake up and it is dark and my phone or computer is nowhere near, because I immediately know that it is not yet 7:36 AM. That is exactly the right amount of information to calm my nerves and to perhaps allow me to enjoy a few more minutes (or hours, depending on how jet-lagged I am) of blissful sleep.

And in fact, that is all the information I required early this morning… if only I had thought of this “alarm” idea before.