18.04.2013 Views

The.Algorithm.Design.Manual.Springer-Verlag.1998

The.Algorithm.Design.Manual.Springer-Verlag.1998

The.Algorithm.Design.Manual.Springer-Verlag.1998

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Other NP-Complete Problems<br />

Next: <strong>The</strong> Art of Proving Up: Intractable Problems and Approximations Previous: Vertex Cover<br />

Other NP-Complete Problems<br />

Clique, vertex cover, and integer programming are just three of the literally hundreds of problems that<br />

have been shown to be NP-complete. It is important to be aware of which kinds of problems tend to be<br />

hard, so you recognize them when you see them in applications, and also to provide a suitable class of<br />

candidates for future reductions. Some, but by no means all, of the hard problems from the catalog<br />

include:<br />

● Integer partition - Can you partition n integers into two subsets such that the sums of the subsets<br />

are equal? See Section for details.<br />

● Bin packing - How many bins of a given size do you need to hold n items of variable size? See<br />

Section for details.<br />

● Chromatic number - How many colors do you need to color a graph such that no neighboring<br />

vertices are of the same color? See Section for details.<br />

● Bandwidth - Which permutation p of the vertices of a graph minimizes the length of the longest<br />

edge when the vertices are ordered on a line, i.e. ? See Section for<br />

details.<br />

A few other catalog problems exist in a limbo state, where it is not known whether the problem has a fast<br />

algorithm or is NP-complete. <strong>The</strong> most prominent of these are graph isomorphism (see Section ) and<br />

primality testing (see Section ). That this limbo list is so short is quite a tribute to the state of the art in<br />

algorithm design and the power of NP-completeness. For almost every important problem for which we<br />

do not know a fast algorithm, we have a good solid reason for why one doesn't exist.<br />

<strong>The</strong> same should hold true for the problems you encounter in your work. One way or another they should<br />

be resolved as being either hard or polynomial. Leaving them in a limbo state is a sure sign of a bushleague<br />

algorithm designer.<br />

It takes experience to be able to sense whether a problem is likely to be hard or not. Perhaps the quickest<br />

way to gain this experience is through careful study of the catalog. Note that slightly changing the<br />

wording of a problem can make the difference between it being polynomial or NP-complete. Finding the<br />

shortest path in a graph is easy, while finding the longest path in a graph is hard. Constructing a tour that<br />

visits all the edges once in a graph is easy, while constructing a tour that visits all the vertices once is<br />

file:///E|/BOOK/BOOK3/NODE116.HTM (1 of 2) [19/1/2003 1:29:54]

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!