[Thomas_H._Cormen]_Algorithms_unlocked(BookZZ.org)

Chapter 1: What Are Algorithms and Why Should You Care? 5
and run both of them on various inputs of various sizes. How, then, can
we evaluate an algorithm’s speed?
The answer is that we do so by a combination of two ideas. First,
we determine how long the algorithm takes as a function of the size
of its input. In our route-finding example, the input would be some
representation of a roadmap, and its size would depend on the number
of intersections and the number of roads connecting intersections in the
map. (The physical size of the road network would not matter, since we
can characterize all distances by numbers and all numbers occupy the
same size in the input; the length of a road has no bearing on the input
size.) In a simpler example, searching a given list of items to determine
whether a particular item is present in the list, the size of the input would
be the number of items in the list.
Second, we focus on how fast the function that characterizes the running
time grows with the input size—the rate of growth of the running
time. In Chapter 2, we’ll see the notations that we use to characterize
an algorithm’s running time, but what’s most interesting about our approach
is that we look at only the dominant term in the running time,
and we don’t consider coefficients. That is, we focus on the order of
growth of the running time. For example, suppose we could determine
that a specific implementation of a particular algorithm to search a list
of n items takes 50n C 125 machine cycles. The 50n term dominates
the 125 term once n gets large enough, starting at n 3 and increasing
in dominance for even larger list sizes. Thus, we don’t consider
the low-order term 125 when we describe the running time of this hypothetical
algorithm. What might surprise you is that we also drop the
coefficient 50, thereby characterizing the running time as growing linearly
with the input size n. As another example, if an algorithm took
20n 3 C 100n 2 C 300n C 200 machine cycles, we would say that its
running time grows as n 3 . Again, the low-order terms—100n 2 , 300n,
and 200—become less and less significant as the input size n increases.
In practice, the coefficients that we ignore do matter. But they depend
so heavily on the extrinsic factors that it’s entirely possible that if
we were comparing two algorithms, A and B, that have the same order
of growth and are run on the same input, then A might run faster than B
with a particular combination of machine, programming language, compiler/interpreter,
and programmer, while B runs faster than A with some
other combination. Of course, if algorithms A and B both produce correct
solutions and A always runs twice as fast as B, then, all other things