Heuristics and Good-Enough Answers

Some problems, like finding the shortest route through many cities, have so many possible orderings that checking every single one would take longer than anyone could wait, even with a fast computer. A heuristic sidesteps this by using a simple, consistent rule to build a solution directly, instead of comparing every possibility. The nearest neighbor heuristic is one example: start at a city, then repeatedly travel to the closest unvisited city, until all cities are visited and you return home. It never looks ahead or reconsiders, it just keeps picking the nearest option at each step.

This produces a route fast, but not always the shortest one. Picking the closest city right now can lock you into a bad position later, forcing a long jump near the end that a smarter global plan would have avoided. Still, the result is usually close to optimal, and for many real situations close enough is exactly what you need, especially when the alternative is waiting an unreasonable amount of time for a guaranteed best answer.

This topic connects directly to the idea of undecidable and intractable problems elsewhere in the unit: heuristics are the practical response to problems where an efficient exact algorithm may not exist. Rather than abandoning the problem, programmers accept a provably reasonable approximation. Choosing a heuristic becomes a tradeoff between speed, simplicity, and how much error is tolerable, which matters a lot more when a small percentage off is costly than when it barely matters.