Why can you check a finished Sudoku in ten seconds, but solving a hard one from a blank grid can take an hour?
Both puzzles have the exact same difficulty on paper. Nine rows, nine columns, nine boxes, the digits 1 through 9. But checking a filled grid and filling one in from scratch are not the same job at all. Checking means scanning each row, column, and box once and confirming no digit repeats. Filling one in means trying digits, backtracking when you hit a wall, and trying again.
That gap, between confirming an answer and finding one, is the whole question behind P vs NP. It's one of the seven Millennium Prize Problems, worth a million dollars to whoever settles it, and nobody has.
Checking is not the same job as finding
Here's a smaller version of the same puzzle. Below is a list of numbers and a target sum. Your job is to click numbers until they add up to the target.
Click numbers until they add up to the target. Checking your answer is instant. Finding one means facing all 64 possible groups.
Notice what happens as you drag up. The list barely grows, but the number of possible groups you'd have to try, in the worst case, doubles every time you add one more number. That's . At that's already over 65,000 possible groups.
But checking any one group you've already picked? That takes one addition. Instant, no matter how big gets.
This is the core asymmetry. Verifying a candidate answer scales gently. Searching for one from scratch scales explosively. Sudoku has it. This number puzzle has it, and it's called subset sum. So does packing a truck efficiently, scheduling exams without conflicts, and folding a protein into its lowest-energy shape.
What P and NP actually stand for
Now that you've felt the gap, here's the notation for it.
A problem is in P if a computer can solve it, from scratch, in a reasonable amount of time, one that grows like a polynomial in the size of the input, think , , or steps.
A problem is in NP if, once someone hands you a candidate answer, a computer can check whether it's correct in that same reasonable, polynomial amount of time. NP stands for "nondeterministic polynomial time," but you don't need the formal machinery: it just means "fast to verify."
Every problem in P is automatically in NP. If you can solve something quickly, you can just as quickly check a proposed answer, solve it yourself and compare. That direction is free.
The open question runs the other way: We write this as:
Subset sum is in NP: hand someone a group of numbers and they can add them up in a flash. Nobody has ever found a way to solve it from scratch in polynomial time for every possible list, and nobody has proven that's impossible either. That's the whole problem, sitting inside a puzzle you just played with.
The hardest problems in NP are secretly the same problem
Here's where it gets stranger. Subset sum, Sudoku, scheduling, and thousands of other problems don't just resemble each other. Many of them can be translated into each other, exactly, using a fast, polynomial-time procedure.
This translation is called a reduction. If you could solve one of these problems quickly, you could use the reduction to solve the other one quickly too, just by translating the input, running your fast solver, and translating the answer back.
Slide the variable count. A boolean-satisfiability puzzle translates into a graph-coloring puzzle whose size grows in step, roughly linearly, while the search space behind either one still explodes.
Watch what happens as the puzzle grows. The Boolean satisfiability puzzle on the left (find true/false values that make a set of logical clauses true) turns into a graph-coloring puzzle on the right. The translation itself stays cheap, growing about as fast as the puzzle does. But the number of things you'd have to search through to actually solve either one still doubles with every added variable.
A problem that every other NP problem can be reduced into is called NP-complete. Solve any single NP-complete problem quickly, in the general case, and you've handed the world a fast solver for all of them at once: scheduling, packing, circuit design, route planning, the lot. That's what makes this one open question so disproportionately valuable. It isn't about one puzzle. It's about thousands of them, all wired together.
So what would change if P turned out to equal NP?
Toggle the hypothesis. If P equals NP, the inner circle of “easy to solve” problems swallows the outer ring of “easy to check” ones.
Toggle the hypothesis above. Right now, P sits as a small, proven-easy island inside the much larger ocean of NP. Nobody knows whether that island secretly covers the whole ocean or not.
If P equals NP, a fast, general method exists for solving every problem in NP, we just haven't found it yet. A huge amount of modern cryptography relies on the opposite belief: that certain problems, like factoring a giant number into its prime factors, are easy to check but hard to solve. If a fast solver existed for NP-complete problems, the reductions we just saw mean it would apply everywhere, including the math protecting your bank login. Most of internet security would need to be rebuilt from scratch.
It cuts the other way too. Drug design, logistics, chip layout, even parts of mathematical proof-finding all involve searching a huge space for something that's easy to check once you find it. A fast general solver wouldn't just break cryptography. It would hand us fast solutions to some of the most expensive search problems we have.
Almost every computer scientist expects P does not equal NP. The evidence is decades of brilliant people failing to find a fast solver for any NP-complete problem. But expecting something and proving it are different jobs, and this is a problem about the difference between exactly those two things. The proof still doesn't exist.
Why "exponential" is worse than it sounds
The reason nobody just brute-forces their way past this isn't a lack of trying. It's that exponential growth outruns any computer we could ever build.
Hit play and watch problem size n climb. The verifier barely notices. The brute-force solver falls off a cliff.
Watch the race. The verifier, running in roughly steps, barely climbs. The brute-force solver, running in steps, looks flat for a while and then goes vertical. By around , verifying takes a fraction of a second and brute-force search takes longer than the universe has existed.
This is why "just try every possibility" stops being a real plan almost immediately. It's also why a fast, general algorithm for NP-complete problems, if one exists, would be one of the most important discoveries in the history of computing. It wouldn't just be a clever trick. It would mean this entire wall, the one separating checking from finding, was never really there.
The short version
Checking an answer and finding one are different jobs, and for a huge class of problems, checking scales fine while finding might not. P is the set of problems solvable quickly from scratch. NP is the set of problems whose answers are quick to check. Every problem in P is in NP for free, but nobody knows if the reverse holds, and thousands of problems, from scheduling to cryptography to protein folding, are wired together through reductions so that solving any single one of the hardest ones quickly would solve them all. Most researchers bet the answer is no, P does not equal NP, but sixty years in, nobody has proven it. The million-dollar prize is still sitting there, unclaimed, alongside the other Millennium Prize Problems.
All visualizations are interactive React components running entirely in your browser. The subset-sum list uses a seeded random generator so it stays stable between renders, and the growth curves are computed directly from and , no lookup tables. No libraries beyond React.