What Is an Algorithm?

A recipe you already follow

Picture making a cup of tea. You boil water, put a bag in a cup, pour, wait, remove the bag. Nobody calls that frightening, yet it has every ingredient of what computer scientists call an [[dsa-algorithm|algorithm]]: a finite list of clear steps that takes some starting stuff (water, a tea bag) and produces a result (tea). That's the whole idea. An algorithm is just a *precise procedure* — a recipe written carefully enough that following it blindly still gets the right answer.

The word can sound intimidating, but you have been running algorithms your whole life: looking up a word in a dictionary, dealing a hand of cards, following directions to a friend's house. The only difference in this course is that we'll write the steps down so exactly that a machine — which has no common sense at all — can carry them out. A computer never guesses what you *meant*. So an algorithm has to say precisely what to do, in what order, with no gaps.

From steps to code: finding the biggest number

Let's turn a recipe into something a computer can run. The task: given a list of numbers, find the largest. As a human you'd just *glance*, but a machine needs the steps spelled out. Here is the recipe in plain language first.

1. Assume the first number is the biggest so far. Remember it.
2. Look at each remaining number, one at a time.
3. If the one you're looking at is bigger than the one you remember, remember this one instead.
4. When no numbers are left, the one you remember is the largest. Report it.

Notice every step is mechanical — no judgment needed. That is exactly why it translates straight into C++:

#include <vector>

// Return the largest value in v. (Assume v is not empty.)
int largest(const std::vector<int>& v) {
    int best = v[0];                 // step 1: first is best so far
    for (int i = 1; i < v.size(); i++) {   // step 2: look at the rest
        if (v[i] > best) {           // step 3: found a bigger one?
            best = v[i];             //         remember it instead
        }
    }
    return best;                     // step 4: report the answer
}

Correct first, and one task, many recipes

The first thing we demand of an algorithm is correctness: for *every* valid input, it returns the right answer. Our recipe is correct because of a small promise that holds the whole way through — after looking at the first *k* numbers, `best` always holds the largest among those *k*. Check it at the start (k = 1, trivially true), and each step keeps the promise true, so by the end `best` is the largest of all. That style of reasoning — a fact that stays true on every pass — is something we'll lean on again in the search guide.

Here's the idea that makes this whole field interesting: the *same* task usually has many correct algorithms, and they are not all equally good. To find the largest number you could instead sort the whole list and take the last element — also correct, but it does far more work than needed. Or to check whether a name is in a phone book, you could read every entry top to bottom, or you could flip to the middle and halve the search each time. Both find the name; one is dramatically faster. Correctness is the price of entry. After that, we compare recipes by how *cheap* they are to run — and that's what the next guides are about.