speak but because they can’t understand or think of sensible things to say. But really it’s not that they can’t do it, more that we don’t know just how we do it ourselves and so we can’t tell the computer what to do. In this section we’re going to look at problems where it’s easy to tell the computer what to do—by writing a program—but the computer can’t do what we want because it takes far too long: millions of centuries, perhaps. Not much good buying a faster computer:
if it were a hundred times faster it would still take millions of years; even one a million times faster would take hundreds of years. That’s what you call a hard problem—one where it takes far longer than the lifetime of the fastest computer imaginable to come up with a solution!
The activities in Part II on algorithms showed you how to find ways of making computer programs run more efficiently. In this section we look at problems for which no efficient so-lutions are known, problems that take computers millions of centuries to solve. And we will encounter what is surely the greatest mystery in computer science today: that no-one knows whether there’s a more efficient way of solving these problems! It may be just that no-one has come up with a good way yet, or it may be that there is no good way. We don’t know which. And that’s not all. There are thousands of problems that, although they look completely different, are equivalent in the sense that if an efficient method is found to solve one, it can be converted into an efficient method to solve them all. In these activities you will learn about these problems.
For teachers
There are three activities in this section. The first involves coloring maps and counting how many colors are needed to make neighboring countries different. The second requires the ability to use a simple street map, and involves placing ice-cream vans at street corners so that nobody has to go too far to get an ice-cream. The third is an outdoor activity that uses string and pegs to explore how to make short networks connecting a set of points.
The activities provide a hands-on appreciation of the idea of complexity—how problems that are very simple to state can turn out to be incredibly hard to solve. And these problems are not abstruse. They are practical questions that arise in everyday activities such as mapping, school time-tabling, and road building. The computational underpinning rests on a notion called “NP-completeness” that is explained in the What’s it all about? sections at the end of each activity. Although the activities themselves can be tackled in any order, these sections are intended to be read in the order in which they appear. By the time you reach the end you will have a firm grip on the most important open question in contemporary computer science.
The technical name for this part is “intractability” because problems that are hard to solve are called intractable. The word comes the Latin tractare meaning to draw or drag, lead-ing to the modern usage of tractable as easy to handle, pliant, or docile. Intractable problems are ones that are not easily dealt with because it would take too long to come up with an answer. Although it may sound esoteric, intractability is of great practical interest because a breakthrough in this area would have major ramifications for many dif-ferent lines of research. For example, most cryptographic codes rely on the intractability
phoney bank transactions. We will look at these things in Part V—Cryptography.
For the technically-minded
To make precise the idea of really hard problems, we begin with a measure of the size of a problem, and work out how the amount of computation required to solve it grows as the problem size increases. For example, searching for an item in an unordered list—perhaps searching through a city telephone directory for the person whose telephone number is 982–1735—is an operation whose time, on average, grows in direct proportion to the size of the list. This is known as a linear-time algorithm. Searching an ordered list—
perhaps searching the directory for the number of a particular person—can be done using the binary search strategy (Activity 6) in a time which, on average, grows logarithmically with the size of the list, a logarithmic-time algorithm. Sorting the list into order in the first place using the selection sort method (Activity 7) takes time that grows with the square of the size of the list, a quadratic-time algorithm. (Insertion and bubble sorts are also quadratic-time algorithms.) Sorting using the quicksort and mergesort methods (also in Activity 7) actually takes average time proportional to n log n for a list of length n—
which is a lot faster than a quadratic orn2 algorithm.
For some problems we have a lot of trouble finding fast algorithms. How bad can it get? Well, there are algorithms that take cubic time, quartic time, indeed nq time for any given value ofq. These are all called “polynomial-time” algorithms because the time taken grows polynomially with the problem size. Polynomial growth may sound bad, especially for high-order polynomials, but it can get much worse than that. Exponential-time algorithms are ones whose execution Exponential-time grows with 2n(or indeedqn) for a problem of size n. The problem size is an exponent, which means that once n becomes large enough, the problem outgrows any polynomial function, whatever the power.
What we encounter in these activities are problems for which the only algorithms known are exponential ones. The great unsolved question of computer science is that no-one knows whether polynomial-time algorithms exist for these problems.