Complexity

Symptom You need to test whether two arithmetic circuits compute the same polynomial. The deterministic approach is to expand both into normal form, and the expansion is exponentially large. The randomized approach takes four lines. Pick a random point, evaluate both circuits there, compare. If they differ as polynomials, the Schwartz-Zippel lemma says a random point catches it with probability at least $1 - d/|S|$. Repeat a few times and the error is negligible. ...

Symptom You have a string algorithm. Edit distance between two sequences, the classic dynamic program, $O(n^2)$ time. It has been in production for years. Now the inputs are genome-scale. At $n = 10^5$ characters, $n^2 = 10^{10}$ operations, about 10 seconds at a billion ops per second. At $n = 10^6$ it is $10^{12}$ operations, about 1000 seconds — seventeen minutes for one pair of strings. You need to do a million pairs. ...

Symptom You have just read T030 and you are demoralized. Relativization kills the techniques that treat machines as black boxes. Natural proofs kill the combinatorial ones, assuming pseudorandom functions exist. Between them they appear to rule out everything anyone knows how to do, and the honest summary of fifty years is that nobody can prove any interesting problem is hard. ...

Symptom Your problem is NP-hard, and yet it keeps being easy. You are computing a minimum vertex cover to select monitoring points in a network. Twelve thousand nodes. NP-hard, per T028, so you brace for the worst — and the answer comes back in under a second, every time. The cover is small, around thirty nodes, because the network is sparse and the interesting nodes are few. ...

Symptom You have accepted that the problem is NP-hard. Now what? The literature offers a wall of results with numbers attached: 2-approximation, $\ln n$-approximation, PTAS, FPTAS, 0.878. Nobody explains what these numbers buy you, how they are proved, or how they connect to the heuristic you already wrote. Meanwhile your greedy heuristic is running in production and you have no idea whether it is within 5% or a factor of 50 of optimal, because you cannot compute the optimum to compare against — that was the whole problem. ...

Symptom You gave up on exact (T028) and went looking for an approximation. Vertex cover: you find a 2-approximation in four lines. Knapsack: an FPTAS, any accuracy you want. Encouraged, you go looking for the same for max-clique, and you find nothing. Not “nothing good” — the best known ratio is around $n/(\log n)^2$, which on a 10,000-vertex graph means the algorithm might return a clique nearly 60 times smaller than the true maximum. That is not an approximation, it is a rumour. ...

Symptom You have read T026 and T027 and you are wondering the obvious thing. Fifty years. Thousands of researchers. A million-dollar prize. And P vs NP has not moved. That is strange — most famous problems yield partial results, near misses, special cases that suggest the shape of the answer. Here there is almost nothing. We cannot even prove that NP requires more than linear-size circuits, which is a laughably weak statement compared to what everyone believes. ...

Symptom Three weeks into a project, you are still trying to write an exact algorithm. The problem is yours and it looks specific: assign delivery vans to routes such that every stop is covered, no van exceeds its capacity, and the total distance is minimized. Nothing in the literature matches it exactly. So you keep going — better data structures, smarter pruning, a cleverer greedy pass with a repair step — and each version works on your test set and falls over on production data. ...

Symptom You know reductions (T017): to prove your problem hard, reduce a known-hard problem to it. Fine. But that begs the obvious question, and it is the question a sharp colleague asks the first time you use the technique. ...

Symptom You are handed a scheduling problem. Two hundred tasks, precedence constraints, shared resources, and a deadline. Somebody wants an optimal schedule. Checking a proposed schedule takes seconds: walk the list, verify each constraint, add up the makespan. Finding one is different. Your search runs for a day and finds nothing. You try simulated annealing, then a genetic algorithm, then branch and bound. Each gives good schedules and none gives the best one, and you cannot tell whether the problem is hard or you are not clever enough. ...

Symptom You have a new problem. Your build system needs to decide whether two configuration files can ever produce conflicting outputs. Or your linter needs to decide whether a regex with backreferences can match a string of a given length. Or your scheduler needs to decide whether a set of periodic tasks is feasible. ...