From Pin to Pin

In practice

A rider drops two pins and asks for the fastest way. The city becomes a problem model (0120): intersections and roads kept, weather and scenery erased — someone's judgment call, working as intended. The model lands in a graph (0101): vertices for intersections, weighted edges for travel times, and that modeling decision was the hard work. Underneath, structures divide the labor by their contracts (0095): a map (0099) binds street names to vertices, an array list (0103) holds each vertex's neighbors for one-step access, a search tree (0107) keeps the place-name index findable, and a priority queue (0110) feeds the route algorithm its next-closest intersection. The shortest path problem (0153) is the formal shape of the rider's question, and the algorithm answering it is greed with a proof (0138, 0152's lesson traveling): always extend the cheapest known route, provably safe here. Every piece was chosen by count (0125) and named by growth (0128): the sorted index pays merge sort's O(N log N) once (0145) so binary search can answer in O(log N) forever after (0144), and the whole route computation stays polynomial — class P (0161), the tractable side of the street. One block over sits longest path (0164), the same map and a question no known algorithm answers efficiently — the boundary of the neighborhood, drawn by theory. The rider sees none of it: a line on a screen, in under a second, resting on every idea this unit numbered.