Really though, I find their earlier work, The Table: Childhood, to be the superior piece of autonomous furniture artwork (though less impressive technically).

On a more pragmatic note, Matt seems to have quelled his typical worries over an imminent robot uprising. Instead he expresses concern that most robotics work is being funded by DARPA, and thus conducted with military applications in mind.

My impression, as a CS graduate student, is that DARPA (as oppose to NSF or NIH) funded research has access to much more money, but also more demands/pressure. This wasn’t always the case, and I do get the sense that attitudes toward DARPA funding has soured some in the past decade.

Getting an NSF grant is quite competitive, and hence professors tend to devote a lot of their time to grant writing. Also, a typical grant is not that large (say enough to support one or two graduate students for a few years), but once you have a grant, you need only submit annual progress updates, which are typically brief. The main “accountability factor” for such grants is one’s reputation. If you don’t publish valuable results, you’ll have a hard time getting future funding.

In contrast, DARPA grants can provide much larger sums of money for large projects of military interest (for example, bionic arms). Grant recipients, however, are likely required to produce quarterly progress updates, travel to progress reviews, and be available for meetings/presentations. As such, DARPA funded research is more susceptible to external pressure. Obviously this isn’t necessarily a bad thing, but it’s enough to make some academics reluctant.

In the case of robotics, I do think a lot of fundamental tools (for example, better object recognition, automatic path planning, object manipulation) could be developed in the context of a DARPA grant. The primary difference would be that the military provides access to fancier hardware. For example, iRobot makes small, inexpensive vacuums for consumers, and rugged but pricey PackBots for the military (they’re built Ford tough).

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.

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.

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.

I took a bunch of programming classes in high school, but when I got to Brown, I decided to avoid computer science. I had liked learning about algorithms, the fastest ways to solve problems, how computers worked, but I hadn’t always liked the personality of my fellow students. Basically, a lot of them were big nerds, and I could never get behind their enthusiasm for mastering Linux commands.

As a freshman at Brown, I took a logic class where I learned that certain easy to state problems are uncomputable, meaning no systematic set of instructions can be used to solve them. More importantly, I learned that many people study the science of computation without actually writing programmings. The next year I decided to give computer science another shot, and one of my TAs (my buddy Kevin) invited me to join his group independent study project on computational complexity. After that, I was sold.

So where am I staying until Thursday? Why the lovely Doubletree Hotel in Dallas of course, as I’m currently attending the Semiconductor Research Corporation’s (SRC) annual integrated systems review at Southern Methodist University (SMU). It is indeed an abrupt transition for someone coming from SXSW interactive in Austin.

In retrospect, it seems silly that I didn’t write more about SXSW interactive, an eminently blogable conference, while I was there. I’ll correct this oversight tomorrow after my presentation at this SRC event. For now, I’ll note that my trip to Dallas has proved shockingly beneficial. At dinner I discovered that the engineering graduate student I was sitting next to had cited a paper of mine in his paper on nanowire address discovery. This got me pretty excited, because I hardly ever meet anyone who works in my area of research, and I was literally writing about address discovery the day I left for Texas. Also, before tonight, I only knew of one other paper on this subject.

Anyway, if conference summaries aren’t your thing, here’s a picture of the SMU’s ironically named life science building (sorry about the hard to read photo).

Since this is a pretty big day for both me and XKCD, I though I should spend a few paragraphs explaining (to the non-CS types out there) exactly why this comic is so goddamn hilarious.

The Turing test was originally proposed in 1950 by pioneering logician and computer scientist Alan Turing. About 20 years earlier, Turing described a simple machine, now called a Turing machine, that could perform only a few simple operations. He then showed how the machine could be programmed to carry out arbitrarily complex computations. In doing so, he provided the theoretical basis for modern day computers.

By the 1950’s, actual computers were being built, and folks realized that a sufficeintly large computer, when properly programmed, could appear intelligent. People wondered if computers could one day “think” like people, but in many ways this question was vague. To clear things up, Turing proposed a hypothetical test of a computer’s intelligence. During a Turing test, a computer is allowed to communicate with a person through writing. If, after a long conversation, this human cannot accurately distinguish the computer from another person, the computer is deemed as intelligent as a person. As you know, today’s computers cannot yet past the Turing test.

So there you go, you’re finally ready to laugh. The Turing test is a way for a machine to prove that it’s truly intelligent. To do this, the machine must convince an examiner that they are talking to another person. If you were to take the test (in place of the machine), you’d no doubt pass, but it’d take some sort of Hannibal Lecter-type supergenius to convince another person that they were a computer. The comic’s suggestion that a machine could pull this off is delightfully absurd, plus a perfect set up is provided by referencing “extra credit” on a pass/fail test for computer intelligence. Finally there’s the illustration itself, a hilarious vignette in which the anonymous gray computer terminal has forced a now deeply-confused examiner to question the very essence of his being. It all fits together beautifully! I can’t wait to stand outside my office and look at it.

Second, here’s a hot video demoing some content-aware image resizing research first presented at SIGGRAPH 2007. It’s a fairly simple idea that works surprisingly well.

Normally when you shrink an image you either make the whole thing smaller, or crop some content from the sides. Ariel Shamir and Shai Avidan take a different approach which they call “seam carving”.

As the video explains, seam carving is similar to removing the least important rows and columns from the middle of an image. Instead of removing rows and columns, however, their algorithm identifies paths of unimportant pixels. These paths tend to curve around objects, so when removed, they shrink the image in way that’s not very noticeable. Basically you end up shrinking an image by removing the space between objects, but not changing the size of the objects themselves.

If you have some images you need to resize intelligently, a rather pricey photo shop plugin is available here. Alternatively, here’s a free plugin for GIMP (which is also free).

Finally, if you’re still hungry for more content-aware image editing, here’s a paper by Microsoft researcher Antonio Criminisi. Sadly there’s no flashy video, but the images in the paper do give some very impressive examples of how their algorithm automatically fills in missing regions of images. By filling in a missing region, one can also delete entire objects from a scene, remove overlaid text, or stitch together partially overlapping photos.

I’m avoiding the temptation to rehash Steven’s more detailed example and Wikipedia’s explanation. Instead, I just wanted to highlight both pages as an illustration of what computer science is all about. Computer scientists don’t sit around and multiply numbers all day, but we also don’t write computer programs all day either. Instead we worry about the best way to solve problems (often problems involving numbers). Early on computer scientists realized that binary representations of numbers made it simpler to design circuits that performed arithmetic. They also asked questions like “How many steps does it take to multiply two number?”

Whether done by a computer, a person, or some sort of trained animal, the algorithm described above takes about the same number of steps as the traditional method we all learned in school. If you have two n digit numbers, the number of steps required is proportional to n*n (here a “step” means multiplying two digits, or adding two digits). The advantage of the nontraditional algorithm is that you don’t need to remember anything from a multiplication table, you just need to know how to know how to add digits and divide by 2.

It turns out that much faster algorithms exist. If you (or your computer) ever need to multiply two very long numbers, the Karatsuba Multiplication Algorithm requires many fewer steps. For small numbers, however, it’s more complicated, so don’t feel bad about not knowing about it.

A young man is committed to marry one of three identical sisters. Despite their genetic similarity, one of the sisters always lies, one always tells the truth, and the third lies only sometimes. Also, the sisters themselves can always tell each other apart. The young man is permitted to ask one of the women, chosen at random, a single yes-no question. Based on this single response, he must select his bride. Being a man who values certainty, his goal is to select either the sister that always tells the truth, or the sister that always lies. What question should he ask?

Whatever question is asked, the response is either yes or no. When the question is asked to the sister that sometimes lies the response is meaningless. Regardless of what she says, the man must select one of the other two sisters. Since the man does not know which sister he is addressing, his question and response to it’s answer must always be the same. Thus his response to the answer must always be to select one of the two sisters he did not address.

So the man needs a question that differentiates between the two sisters not being addressed. When the sister that sometimes lies is addressed, it doesn’t matter which other sister is chosen. When the sister who always lies is addressed, however, the truthful sister must be selected, and when the sister who always tells the truth is addressed, the sister that always lies must be selected.

The man’s question must cause the always lying sister to identify the truthful sister, and the truthful sister to identify to the always lying sister. Since the lying sister always lies, the question should ask her to identify the sister that sometimes lies, while at the same time ask the truthful sister to identify the sister that always lies.

One such question is “Which of your two sisters always lies, or if neither always lies, which sometimes lies?” A much nicer version of this question is: “Which of your two sisters lies more?”. To turn this into a yes-no question, the man can simply point to one of the other two sisters and ask “Does she lie more than your other sister?”.

In the end, this puzzle has a nice short answer. From a computer science perspective, I think understanding how one can arrive at this answer is what’s interesting.