What Is an Algorithm? Everyday Words and Pseudocode

Directions to a friend's house are an algorithm. "Leave the station, walk two blocks, turn left at the bakery, and it is the third door on the right." The steps are in order, each one is clear enough to follow without guessing, and the list ends when you arrive. Nobody calls this programming, yet it has the same shape as the instructions a computer follows.

An algorithm is a finite, ordered set of clear steps that solves a problem or reaches a goal. The word sounds technical, but the idea is older than computers. This entry explains what makes a list of steps a good algorithm, how to write one in everyday words and in pseudocode, and how two different algorithms can solve the same problem at very different cost.

What makes something an algorithm

The NIST Dictionary of Algorithms and Data Structures gives a short definition: a computable set of steps to achieve a desired result. In practice, a good algorithm has these properties:

• Input. It starts from some given data, such as a list of numbers or a range to search.
• Output. It produces a result, such as the highest number or the position of an item.
• Clear steps. Each step is exact. "Pick a good number" is not a step, but "pick the middle number" is.
• Finite. It ends after a limited number of steps. A list of steps that never stops is not an algorithm for solving the problem.
• Correct. It gives the right answer for every valid input, not only for the one you tried.

Notice that the definition says nothing about code. An algorithm is the idea, and a program is one way of writing the idea down so a machine can run it. You can use the same algorithm in Python, in another language, or on paper.

Describing an algorithm in everyday words

The simplest description is a numbered list in everyday words. Take a small problem: given the daily high temperatures for a week, find the warmest day's temperature.

1. Look at the first temperature and remember it as the highest so far.
2. Move to the next temperature.
3. If it is higher than the one you remembered, remember this one instead.
4. Repeat steps 2 and 3 until there are no more temperatures.
5. The one you remember is the answer.

This works because step 1 gives you a starting champion, and each later number either beats it or does not. After one pass over all the numbers, the champion cannot be beaten. The same method works for 5 numbers or for 5 million.

Pseudocode: between words and code

Pseudocode is a way of writing an algorithm with the structure of code but without strict language rules. It uses words like IF, FOR EACH and SET, and nobody expects it to run. Its job is to let people agree on the logic before worrying about syntax. There is no single official style, so any consistent, readable one is fine.

The warmest-day method in pseudocode looks like this:

SET highest TO the first temperature
FOR EACH temperature IN the list
    IF temperature > highest THEN
        SET highest TO temperature
RETURN highest

Compare it with the everyday-words version. It says the same thing in less space, and it already shows the loop and the decision. Turning it into Python is nearly a line-for-line translation:

temps = [14, 19, 23, 17, 21]

highest = temps[0]
for t in temps:
    if t > highest:
        highest = t

print("Highest:", highest)

Trace it by hand. highest starts at 14. Then 19 beats 14, so it becomes 19. Next 23 beats 19, so it becomes 23. After that 17 and 21 do not beat 23. The output is Highest: 23. The loop and decision used here are explained in the entries on loops and if and else. Python also offers max(temps), which does the same job, but writing the steps yourself teaches how the idea works.

A flowchart is a third way to describe the same thing, with boxes and arrows. It suits people who think visually. All three forms describe the same algorithm.

Two algorithms for one problem

Different algorithms can reach the same answer with very different amounts of work. Here is a number-guessing game. A friend picks a secret whole number from 1 to 100, and after each guess says only "too low", "too high" or "correct".

Algorithm A, one by one. Guess 1, then 2, then 3, and so on. It is simple and always works. If the secret is 100, it needs 100 guesses.

Algorithm B, halving. Always guess the middle of the range that is still possible. If the answer is "too high", throw away the upper half. If it is "too low", throw away the lower half. This method is called binary search.

def guess_number(secret, low=1, high=100):
    guesses = 0
    while low <= high:
        middle = (low + high) // 2
        guesses = guesses + 1
        print("Guess", guesses, "is", middle)
        if middle == secret:
            return guesses
        elif middle < secret:
            low = middle + 1
        else:
            high = middle - 1
    return None

print(guess_number(37))

Follow it for a secret of 37. The first middle is (1 + 100) // 2, which is 50. That is too high, so high becomes 49. The next middle is (1 + 49) // 2, which is 25. Too low, so low becomes 26. The next is (26 + 49) // 2, which is 37, and that is correct. The output is:

Guess 1 is 50
Guess 2 is 25
Guess 3 is 37
3

Three guesses instead of 37. Each guess cuts the remaining possibilities roughly in half, so even the worst secret in 1 to 100 takes at most 7 guesses. The table shows how the worst case grows:

The halving numbers come from asking how many times you can double 1 before reaching the range size: 2 to the power of 7 is 128, to the power of 10 is 1,024, and to the power of 20 is 1,048,576. Binary search has a condition, though. The data must be in order, as the numbers 1 to 100 are. Python's bisect module uses the same halving idea to find where a value belongs in a sorted list.

Choosing and judging algorithms

Programmers judge an algorithm on more than correctness. They also ask how much time it needs and how much memory it uses as the input grows. This area is called efficiency, and the table above is a small taste of it. For small inputs the difference rarely matters, so the simplest correct algorithm is often the right first choice. Speed becomes important when the data is large or the step is repeated many times.

A practical routine for designing your own algorithm:

1. State the input and the output in one sentence each.
2. Solve a tiny example by hand and note each step you took.
3. Write those steps in everyday words, then in pseudocode.
4. Check the steps against edge cases, such as an empty list or a single item.
5. Only then write the code, and test it with the same examples. The idea of automating this check is covered in software testing basics.

For the wider context of how code carries out steps, read what programming is, and see the Logic and Programming area for related topics.

Common mistakes

• Vague steps. "Sort things out" cannot be followed by a computer. Every step must be something you could do mechanically.
• Forgetting how it ends. A loop whose condition never becomes false makes an algorithm that never finishes. Always ask what makes it stop.
• Testing with only one example. An algorithm that works for 37 might fail for 1 or 100. Try the smallest, the largest and an in-between case.
• Using binary search on unsorted data. Halving only works when the data is in order. On a shuffled list it gives wrong answers.
• Starting with code. Writing code before the steps are clear mixes two problems: the logic and the syntax. Settle the logic first.
• Assuming faster is always better. A clever algorithm that is hard to read can cost more in bugs than it saves in time. Optimize when you have a reason to.

FAQ

Is an algorithm the same as a program?

No. An algorithm is the method, and a program is one written form of it. The same algorithm can be coded in many languages.

Do I need math to understand algorithms?

Basic arithmetic and clear thinking get you far. Deeper study of efficiency uses more math, but beginners can learn the ideas with small examples.

What is pseudocode used for?

It lets people plan and discuss the logic without worrying about exact syntax. Teams use it in design notes, and learners use it to think before coding.

Are recipes and checklists algorithms?

Informally, yes. They have ordered, clear steps that end with a result. The difference is that recipes rely on human judgment, such as "season to taste", which a computer cannot do.

Where do I see algorithms in daily life?

Search results ordering, route planning, and spell checking all rely on algorithms. The details of any specific product are usually not public, so treat such examples as illustrations of the idea.