Introduction
Some problems are easy to check and hard to solve. A route problem shows the difference in numbers you can work out by hand. This walkthrough takes four towns and a claim about a short round trip, checks the claim, then finds the best trip by trying every possibility. It then counts how both jobs grow as the number of towns grows.
The gap you'll see is the one at the center of the P versus NP question, which asks whether every problem whose answers are easy to check also has answers that are easy to find (Clay Mathematics Institute n.d.-a).
The Starting Point
Four towns, labeled A, B, C, and D, are connected by roads. The distances in kilometers are:
| Road | Distance (km) |
|---|
| A to B | 50 |
| A to C | 80 |
| A to D | 60 |
| B to C | 40 |
| B to D | 70 |
| C to D | 30 |
A delivery driver has to start at A, visit each of the other towns once, and return to A. A round trip like this is called a tour. A colleague claims that the tour A, B, C, D, then back to A is shorter than 200 kilometers.
You have two jobs. First, check the colleague's claim. Second, find the shortest tour of all, and be sure that no tour is shorter.
Walking Through the Comparison
Step 1: Check the claim
To check the claim, add the four distances on the proposed tour and compare the total with 200.
The tour goes A to B (50 km), B to C (40 km), C to D (30 km), and D back to A (60 km). The total is 50 + 40 + 30 + 60 = 180 kilometers. Since 180 is less than 200, the claim is true.
Count the work. You did three additions to combine four distances, then one comparison with 200. That's four steps. For a tour through any number of towns, checking takes as many steps as there are towns: one addition for each road after the first, plus one comparison at the end. You don't need to know anything about other possible tours to do it.
Step 2: Find the best tour by brute force
Finding the shortest tour is a different job. The direct method is brute force: list every possible tour, work out the length of each, and pick the smallest.
Start at A. The other three towns can be visited in 3 \times 2 \times 1 = 6 orders. But each tour can be driven in either direction, and both directions have the same length. A, B, C, D, A is the same round trip as A, D, C, B, A, driven the other way. So the 6 orders give only 3 distinct tours:
| Tour | Calculation | Length (km) |
|---|
| A, B, C, D, A | 50 + 40 + 30 + 60 | 180 |
| A, B, D, C, A | 50 + 70 + 30 + 80 | 230 |
| A, C, B, D, A | 80 + 40 + 70 + 60 | 250 |
The shortest tour is A, B, C, D, A, at 180 kilometers. Because every tour is in the list, you know for certain that no shorter one exists. That certainty is what brute force buys, and what it costs is the work of listing everything.
Step 3: Count the tours for larger maps
With n towns, where n stands for the number of towns, the same reasoning gives (n-1)!/2 distinct tours. Here (n-1)!, read "n minus 1 factorial," means multiplying all the whole numbers from 1 up to n - 1. You fix the starting town, count the orders of the rest, and divide by 2 for the two directions.
For 4 towns, that's 3!/2 = 6/2 = 3, matching the list in Step 2. For 10 towns, it's 9!/2 = 362,880/2 = 181,440 tours. For 20 towns, it's 19!/2, which is about 6 \times 10^{16}, or 60 thousand trillion tours.
Step 4: Compare checking with searching
Put the two jobs side by side. Checking a single proposed tour through 20 towns takes about 20 steps. Searching all tours of 20 towns by brute force means checking about 6 \times 10^{16} of them. A computer that checked a billion tours per second would need about two years. With 21 towns, it would need about 39 years.
Checking grows slowly: add a town and you add one step. Searching grows explosively: add a town and you multiply the number of tours by the number of towns you already had. Going from 20 towns to 21 multiplies the count by 20. This kind of growth outpaces even exponential growth like 2^n, and it's why brute force, fine for 10 towns, is already impractical at around 20.
Step 5: Connect to P versus NP
Turn the route problem into a yes-or-no question: "Is there a tour shorter than 200 kilometers?" If someone hands you a tour, you can check it in a few steps, as in Step 1. So the question belongs to NP, the class of problems whose "yes" answers can be checked efficiently. P is the class of problems that can be solved efficiently, and the Clay Mathematics Institute describes the contrast as "easy to find" versus "easy to check" (Clay Mathematics Institute n.d.-a).
The open question is whether some clever method could find short tours for every map nearly as fast as you can check one, a shortcut through the search that nobody has discovered. If such shortcuts exist for every problem whose answers are easy to check, then P equals NP. Most complexity theorists believe they don't, but nobody has proved it either way (Cook n.d.). Routing and scheduling problems of this kind have real industrial importance (Cook n.d.), so the answer matters beyond mathematics.
Key Considerations
Good routes versus best routes. Real route planners don't use brute force. They use clever methods that find very good tours quickly, often without proving that no better tour exists. That's a different goal from the one in Step 2, where the aim was a tour you could prove is shortest. The P versus NP question is about finding guaranteed answers, for every possible map.
The common mistake: thinking faster computers will make brute force practical. It's tempting to think brute force is only waiting for better hardware. The numbers say otherwise. A computer 1,000 times faster would bring the 20-town search from about two years down to under a day. But each added town multiplies the work again, so the faster machine would be stuck again after only a few more towns. Speed buys a few extra towns, not a solution for large maps.
Checking isn't the same as finding. Step 1 confirmed that one tour is under 200 kilometers. It didn't show that 180 is the best possible. Only the full comparison in Step 2 did that. Mixing up the two jobs hides exactly the gap the P versus NP question is about.
Summary
Checking a proposed tour takes about one step per town, while finding the best tour by brute force means comparing a number of tours that explodes as towns are added.
| Towns | Steps to check one proposed tour | Number of distinct tours |
|---|
| 4 | 4 | 3 |
| 10 | 10 | 181,440 |
| 20 | 20 | about 6 \times 10^{16} |
For the four-town map, the claim "under 200 km" is true (the tour totals 180 km), and A, B, C, D, A is the shortest tour, confirmed by comparing all three tours.
- The checking column counts one addition for each road after the first and one final comparison, which comes to one step per town.
- The tour column is (n-1)!/2, where n is the number of towns.
- Whether a shortcut can close the gap between the two columns, for every map, is part of what the P versus NP question asks.
References
- Clay Mathematics Institute. n.d.-a. "P vs NP." Millennium Prize Problems. Accessed October 13, 2026.
- Cook, Stephen. n.d. "The P Versus NP Problem." Official problem description, Millennium Prize Problems. Clay Mathematics Institute. Accessed October 13, 2026.