In truth, I’m pretty jazzed about seeing Toronto, although I do regret having just missed Canada Day. A lot of Jessica’s extended family lives here, so I’m sure we would have all had a raucous good time celebrating the bold 1867 union of four British Colonies which, a mere 115 years later, resulted in a fully independent Canada (way to wait that one out!). Despite Canada’s rough and tumble beginnings, downtown Toronto looks pleasant and orderly. Plus, if this Wifi-enable bus is any indication, it’s a futuristic wonderland to boot. I’ll keep you posted.

Over the course of my NYC-based only-childhood, my family had a number of cats, although never more than two at once since as my wise father one told me, “Son, when you have three or more cats, you’ve crossed a threshold”. One of our later cats, Moe, was widely recognized as being freakishly friendly, but his feline status still managed to put several of my more dog-oriented friends on edge. The history of cat domestication, it seems, goes a long way toward explaining why the bulk of cats and dogs have such different personalities. Another consideration, however, for why cats don’t always jive with the masses is that non-cat owners don’t necessarily get much exposure to cats.

When I was in elementary school, I was always jealous that dogs, but not cats, got to accompany parents as they picked up their children after school. In New York City, a cat being taken for a walk is a rare sight indeed. So rare in fact, that a single housecat’s walks through central park were recently deemed intriguing enough to warrant an entire New York Times article (complete with multimedia supplement).

Perhaps feline PR would improve if more cat owners took their pets out for a stroll. It’s an unlikely prospect to be sure, but apparently taking your cat for a walk can be far less cumbersome than I suspected, since today, while on broadway between 107th and 108th street, I saw a man confidently walking down the street with his cat perched calmly on his baseball hat. Regrettably, I only got a chance to take his picture from behind (see below), because for some reason I felt awkward running right in front of him to snap a photo. Ridiculous right? He’s walking around with a cat on his head and I’m worried about being discreet.

Since I was already headed to the ATM, I decided I’d walk ahead of him, go inside, then take his picture from the side, but as I was crossing the street I ran into fellow Stuyvesant/Brown/Brown Grad School attendee, Emily Young. When I drew her attention to the man-cat combo, Emily (who lives in the area) didn’t mention having seen them before, so maybe this is a new phenomena. Still, I doubt it’s a one time thing. If you’re the type of guy who decides to go out for a stroll with your cat perched on your head, you’re probably the type of guy who’s game to try it twice.

Last post I explained that in computer science, we typically look for the fastest procedure, or “algorithm”, for solving a particular problem. Furthermore, the “complexity” of an algorithm is typically considered to be the number of steps it requires in relation to the length of its input. For example, you (and also a computer) can add two numbers with n digits using the approach you learned in elementary school. The number of steps required is proportional to n. Multiplying two n digit numbers, however, requires more steps (the standard approach uses about n² steps).

The number of steps an algorithm takes is called its “running time”. When theoretical computer scientists study the running time of an algorithm, they aren’t concerned with the running time on a particular input, they are concerned with how to bound the running time in terms of n, the input length, for large inputs. This makes a lot of sense, since if I told you I’d discovered a way to multiply numbers very quickly, and told you that 318 x 702 = 223,236, you’d rightly suspect that I had just memorized that answer. A real test of my method would be to see how it performs on randomly chosen large inputs. When the running time of an algorithm is at most n raised to some power (for example, n⁷), it is said to run in “polynomial time” (back in high school, you probably learned that x raised to a power is called a polynomial).

Any problem that can be solved by an algorithm that runs in polynomial time is said to be in a class of problems that is very sensibly denoted P. An algorithm that takes n¹⁰⁰ steps to run will take a very long time to run, so it is not true that any problem in P can be solved quickly. In practice however, many many useful problems in P can be solved quickly. Furthermore, problems not in P can be extremely hard to solve even for relatively small inputs. For example, if an algorithms running time is 2ⁿ, it does not run in polynomial time, and in fact there isn’t even enough time in the universe for it to run on arbitrary inputs of length 100 (if each step of the algorithm takes only a nanosecond, executing 2¹⁰⁰ steps would still take far longer than the estimated current age of the age of the universe).

Over the last 40 years, diligent computer scientists have identified a host of practical problems that do not appear to be in P. Some of these problems, even though we do not think they can be solved in polynomial time, can still be checked in polynomial time. As an example, suppose you were asked to pack n objects in a box. You might need to try many arrangements of these objects before determining that they could, or could not, fit in the box. Notice, however, that if I told you they could fit in the box, I could prove this fact quite quickly by actually packing them in the box. Simply put, the box-packing task may be hard to solve, but a correct solution is easy to verify.

Box-packing makes for a nice example, but as explained in part one of this lengthy exposition, computers like numbers. Put another way, before a computer scientist can study a problem, it needs to be precisely specified using numbers (or at the very least, symbols). In the case of box-packing, each object can be described as a collection of points in space, and the end goal, fitting the objects in a box, can be described by a large number of mathematical relationships. These relationships, which assert that no point lies outside of the box, and no point from one object lies inside another object, hold true only when the objects are packed properly in the box. Clearly the use of numbers has made our nice example irritatingly complex!

To keep things simple, but still be precise, we can instead consider a related problem, which computer scientists call “subset-sum”. In subset-sum, you are given a list of n numbers and asked if there exists some subset of those numbers that adds up to a given target value. Similar to box-packing, this problem can be solved by trying all combinations of the numbers (of which there are 2ⁿ). A correct solution, however, can be verified quickly, since once a correct subset is revealed, adding it up takes very little time.

There are a whole host of problems that, like subset-sum and box-packing, appear hard to solve (i.e. not to be in P) but easy to verify (i.e. the task of verifying that a given solution is correct, is in P). Problems that can be verified (but not necessarily solved) in polynomial time belong to a class called NP (the “N” stands for nondeterministic, but that’s a whole other can of worms).

Any problem that can be solved in polynomial time can be verified in polynomial time (just re-solve the problem and make sure you get the same answer), so any problem in P is also in NP. The million dollar question (literally) is whether P = NP, meaning “Is every problem in NP also in P?” Computer scientists the world over strongly suspect that the answer is “no”, but no one has a proof, and in fact, no one even feels like they are anywhere close.

If someone were to prove that P is not equal to NP that person would necessarily prove that some problem in NP cannot be solved in polynomial time, but in fact, they would also prove something far stronger. Problems such as subset-sum and box-packing aren’t just in NP, they are “NP-complete“. This means that they can both be restated in terms of each other. For example, in polynomial time, one could take the irritatingly complex box-packing problem that we alluded to above and transform it into a subset-sum problem. This can be done not just for the box-packing problem, but for every single problem in NP. As a result, if subset-sum, or any other NP-complete problem can be solved in polynomial time, so can every problem in NP. This means that if P does not equal NP (as computer scientists suspect), no NP-complete problem can be solved in polynomial time.

The existence of NP-complete problems was first revealed in 1971. Soon after, many well-known problems were shown to be NP-complete. For example, the problem of finding the shortest route that visits a certain set of cities, called “traveling-salesperson”, is NP-complete. “Independent-set”, the problem of determining whether a party contains some set of n individuals such that no two have ever met, is as well.

It is fascinating a that broad class of well-known problems are all “equally hard”, meaning that either they are all in P, or none of them are. This is exactly the type of thing that gets theoretical computer scientists excited. Even though there is still no proof of whether or not P = NP, the search for a proof has led to further insights about the nature of solving problems. One of these, the PCP theorem, will be the focus of part three of this post.

A final note: Since we do not expect that P = NP, we do not have algorithms that solve NP-complete problems in polynomial time. In practice, however, certain inputs to certain problems can still be solved fairly quickly. For example, subset-sum is easy to solve when the numbers involved are only one digit long. Also, in the real world, when someone has an NP-complete problem that they need to solve, it is often possible find a solution that is “close” to correct. For example, even when many large numbers are involved, subset-sum can be solved in polynomial time if one is only required to find a subset that adds up to within 10 percent of the target value. None-the-less, it is still easy to generate many, many examples of NP-complete problems that we do not have a way to solve in any reasonable amount of time.

The most memorable—and as an 18 year old, inspirational—exhibition was the kinetic sculptures of Arthur Ganson (and fortunately for you, it’s still there). As an artistically inclined computer scientist who’s also a pretty good juggler, I’m essentially Ganson’s core demographic. Had Brown’s sculpture class been easier to get into, I think I would have produced similar works, but alas, it was not to be. For now, I continue to attend Brown, diligently focusing on the far less physical world of computer science. To that end, I just came across Arthur Ganson’s TED Talk, which I’ve embedded below.

With so very many computers in the world, they cannot all be connected directly. Instead, messages between computers are routed around the globe by glorious web of intermediary computers, all working in tandem to get billions of information packets to their intended destinations. If it helps, you can imagine the whole network as an electronic version of UPS.

The beauty of this system is that it is decentralized, efficient, and robust. Lots of computers are all working together to send lots of information, and there is no single point of failure. A concern, however, is privacy. When your computer sends a message, the random assortment of computers that help deliver your message all have a chance to take a peek. If you are merely visiting this website, eavesdropping is hardly a concern. The content of this site is public, so there’s no problem with some nosey computer reading the sites content en route. Sometimes, however, your computer needs to send private information over the internet.

What if you send google your gmail your password? Or log in to your employer’s computer system? Or give amazon your credit card number? In all cases, the message you’re computer is sending needs to be kept secret. What’s needed is a way to put the message in some kind of “locked box”, and that’s where cryptography comes in. When private information is sent, the computers involved can encode their messages using some slightly fancy mathematics. When done properly, only those two computers will be able to decode each others messages (i.e. open each others’ boxes). The intermediate computers routing their messages will no longer be able to read their content.

Lots of folks write software that sends information over the internet, but most of these people are not about to learn how to write cryptographic protocols for securely sending messages in mathematically sealed boxes. Fortunately for everyone, there are standard tools available. One of them, called OpenSSL, implements a secure message transmission protocol called SSL.

Your computer uses SSL every time you visit a web address that begins with “https:” (instead of the standard “http”). When you see the “s”, it means that the messages your computer is sending and receiving are secure (i.e. inside a locked box). If you tell google your gmail password, and your computer is following the SSL protocol properly, your password will be safe from snoopers. Almost all software that sends private information over the internet relies on SSL. This (at least!) brings me to the point of this post.

Last week, the folks who maintain Debian, a popular version of Linux, announced that they had mistakenly altered OpenSSL. As a result, for several years, programs running on a computer using Debian Linux (or a related distribution), and relying on SSL, were critically flawed. Such programs were all sending their secure messages (as well as possibly generating user passwords) using a very small number of random numerical keys. As a result, the encrypted information could be decrypted (i.e. unlocked) by testing all possible keys. In other words, it’s as if OpenSSL, running on Debian Linux, was choosing all of its passwords from a very small dictionary.

Now most people use Windows or Mac OS X at home and at work, but many websites (and other internet services) run on computers using Linux, since it’s free and open source. When your computer sends secure information over the internet, however, you not only rely on your computer’s ability to use SSL correctly, but also on the computer you are communicating with. This computer is very likely to be running Linux, and though only certain versions of Linux were affected, this recently discovery speaks to a very serious problem. This recent (and massive) security flaw was introduced when some poorly informed developer (lots more info here, also here) modified a grand total of two (2) lines of codes. (and if you’re curious how this poor schlub got his position in the first place, here’s your answer)

If you care to read this discussion thread (which is quite technical), you’ll discover that the lines in question were causing a software debugging tool called Valgrind to report errors. The errors were due to OpenSSL telling Linux to read information from a random location in memory. Valgrind was reporting this as a mistake, since normally when a program accesses a random locations in memory, it is a mistake. In this case, however, the random information was being used to generate a random key to securely encrypt information. When the developers told Linux to ignore the two lines of code, they prevented OpenSSL from properly generating random keys. As a result, internet-related programs running on Debian Linux were all encrypting messages using a very small number of keys, which in turn made the encrypted data very easy to unlock (provided the eavesdropper was aware of this shortcoming).

In the world of computers, finding a security flaw is not uncommon, and I wouldn’t normally spend time writing such a long post about such a technical subject. My concern, however, is that this security flaw has not gotten any attention outside of the world of nerdy websites. It seems to me, however, that a computer security flaw of this magnitude (and of course the potential for even larger flaws) is a public policy issue.

A typical security flaw allows an intruder to gain access to a single computer, or perhaps a computer network, but this flaw does all that and more. With so many computers affected for such a long period of time, you have a real potential for economic disruption (dare I say, even a cyberattack).

Furthermore data encrypted by faulty versions of OpenSSL remains vulnerable even now that the flaw has been discovered (and hopefully on most computers, and faulty passwords, fixed). If someone were monitoring and recording encrypted internet communication (I imagine China does this), they could retroactively use information about the OpenSSL flaw to decrypt all sorts of recorded data. Not only would private information be revealed, but compromised passwords would make additional computer systems vulnerable. Incidentally, there are methods for ensuring that encoded information cannot be discovered retroactively, but these methods are not necessarily used by OpenSSL.

Update: I should have also linked to this slideshow documenting James Fallows trip to the Wolong Panda Reserve.

For right now, I’m not even going to state this theorem, since understanding the theorem requires some background information. I’ll provide some of that background in this post, more next post, and then state the theorem in the third. Regardless, it’s not actually the statement of the PCP Theorem that’s important, it’s the consequences of the theorem. If you understand these consequences, you understand a lot of what theoretical computer science is about. Unfortunately I’ve never seen a plain English explanation of the theorem that is accessible to non-computer scientists. I’m hoping the next few posts will help fill this void.

The PCP Theorem, and complexity theory in general, is concerned with the resources required to solve certain problems. For example, how long does it take to multiply two numbers? Obviously if you do it by hand, it takes longer than if you use a calculator. What’s important, however, is that whether you use a pencil and paper, a calculator, or a super computer, the time it takes depends on the length of the numbers. Suppose you multiply two numbers with n digits each. Using the procedure you learned in elementary school, the amount of time it takes is going to be proportional to n². The same is true for a computer that has been programmed to use the same procedure. As I mentioned once before, faster approaches are known, but these approaches as well can be executed by computers and humans alike.

In computer science (and in other fields too) we often try to identify the fastest procedure, or algorithm, to solve a given problem. Usually algorithms are described by writing a computer program, but this is just a formality. Once a problem has been specified in terms of numbers, or symbols, telling a computer how to solve it isn’t too different from telling a person how to.

You can tell a person to “find Rhode Island on a map”, but you can’t program a computer to do this unless you first specify how the map, and Rhode Island, are represented. If, however, you have a list of cities and the distances between them, you can program a computer to find the shortest route that visits each of the cities. The key is that the problem has been well defined using symbols. In a computer, if you want to something with images (or sounds, smells, etc…), you need to first represent them using combinations of symbols.

So here’s the general story: If you study computer science, you’ll come across with a whole host of nicely specified problems. You’ll learn that a computer can be programmed to solve these problems. Once you get the hang of it, you’ll see that the steps a computer performs when solving these problems are basically the same steps a person would perform. As a result, you’ll understand that it makes sense to study how hard a problem is by determining how many steps it takes to solve, given its length. The main goal of complexity theory is to try to understand why some problems are fundamentally harder to solve than others. So far, this has proved difficult, but complexity theorists have identified many problems that they strongly suspect are hard to solve. In fact, if you could prove that any one of these problems is hard to solve, you would simultaneously prove that all of them are hard to solve, and you would win one million dollars. More on that next time.

As I mentioned last month, one reason for my dearth of posts was that I was busy teaching a class on computational complexity. I was also rushing to submit a paper to a workshop (but then the deadline got extended), and to submit a finalized version of this paper. Despite my absence from the Providence blogging community, however, I’ve remained fully entrenched in the blogging lifestyle.

First off, despite my dire predictions, Passive-Aggressive Notes did end up winning a Webby. It turns out that there was both a “People’s Voice Winner”, and a “Webby Award Winner”, which I assume was awarded by a select panel of internet experts (along with David Bowie). It’s no surprise that Passive-Aggressive Notes is the clear preference among educated elite, where as the web surfing masses mostly enjoy crudely captioned pictures of confused cats. (Speaking of which, I saw faildogs.com for the first time yesterday, frickin’ awesome!)

Now I know what you’re thinking, with Passive-Aggressive Notes already having won both a Webby and the SXSWi Best Blog Award, how am I going to continue to fill this blog with posts devoted to the winning of web awards (or “award winning posts” as I like to call them). That was my primary concern as well, which is why I shrewdly decide to support a second found-content blog. Last Thursday was the official debut of the EERac-supported version of Postcards From Yo Momma.

Postcards From Yo Momma is a collection of motherly emails and instant messages. The site’s creators were previously hosting it on tumblr, which is a bit sparse for my taste (particularly for a site that’s already landed a book deal). Since we were able to get the new version of the site up in time for Mother’s Day (Hi Mom!), its launch happened to coincide with it being featured on newsweek.com and npr.

Now that the madness of getting the site up in time has subsided, I’d love to hear suggestions for making the site better. In fact, several of my friends were already kind enough to explain to me why my initial design totally sucked. A few of the sites few commenters have also echoed their concerns, but the internet does tend to lend itself to that sort of thing. At the very least, I’m confident that if we switched back to the old, ultra-minimal design, there’d be a lot more complaints (except no one would hear them because the old site didn’t even allow for comments).

So there you have it, a new award and a new site. Plus two weeks ago I went to a book-release party for prominent political blogger (also my childhood friend), Matthew Yglesias. Viva la blogosphere!

Expanding existing public transportation infrastructure (particularly trains and subways) is often very expensive. Thanks to global warming and rising gas prices, these expenditures are increasingly worth while, but you can get even more bang for you buck when you simultaneously consider how relatively cheap technology can make existing public transportation work much better. Google Transit is just one example.

My favorite example is using GPS to track the locations of buses. This allows travelers to check bus/train locations, as well as expected arrival times, on the web or their phone. It also would allow transit systems to display the expected weight times at stops. Taking a bus or subway late at night, or in bad weather, is a lot more pleasant when you can time your departure so you don’t have to wait at a stop for 15 minutes.

Earlier this semester, some grad students and I boldly attempted to make this GPS-enabled future a reality. We submitted a proposal, as part of Brown’s initiative to curb carbon emissions, to get money to put GPS-enabled cellphones on select Providence buses. We would have used the GPS data, in conjunction with software my friends had already written, to display bus locations on the web and/or smart phones. We also would have allowed students to use text-messaging to find out what bus they should take to get somewhere, and when they should leave to catch said bus. In fact, we even pointed out that our highly-location specific services would be perfect for generating ad revenue to offset the cost of the GPS. Sadly Brown rejected our proposal, saying that our idea was too “business-like” (which I took to mean, “too well thought out and practical”).

In my home town of NYC, I’ve heard plenty of people complain about the high cost of expanding the subway system. I’ve also heard plenty of people complain that taking buses in outer boroughs sucks. I’ve never, however, heard anyone suggest, that NYC make the bus system better by 1) allowing people to know where buses are or 2) allowing buses to know where trains are, so they can time their arrivals and departures better. At the very least, why not put train information online? Does the MTA honestly not know where it’s trains are at any given time? Isn’t this information already on a computer somewhere?

Once the MTA put train location data online, websites such as hopstop would leap at the opportunity to integrate this data with their existing services. Even if they currently don’t know where their trains are, cell phone service is coming to subway platforms, so service providers will soon be able to use cell phone signals to provide this data. In short, what the MTA really needs is a computer science consultant.

These box-shaped melons were first cultivated by farmers in Zentsuji, Japan to facilitate packing, and might I say, mission accomplished! Still, if Japan is so pressed for space, they should probably get to work scaling down their quadruple-decker hamburgers.