What is an Algorithm

Why this concept matters

When people first learn programming, it can feel like the computer “just does things.” But computers don’t understand goals like “find the best route” or “put these numbers in order.” They only follow instructions.

An algorithm is the bridge between a human goal and mechanical execution.

• •You have a problem (e.g., “find the largest number in this list”).
• •You write a procedure (a sequence of steps) that always works.
• •A computer (or a person) can follow those steps exactly.

Learning what an algorithm is gives you a vocabulary for everything that comes later: correctness, efficiency, data structures, and eventually Big O notation.

Definition (with the key idea)

An algorithm is a finite, ordered sequence of unambiguous steps that transforms input into output.

We can summarize it as a mapping:

input → process → output

Using the key symbol:

input → output (via a well-defined procedure)

Intuition: a recipe, but stricter

Algorithms are often compared to recipes. That’s helpful, but algorithms are stricter than most recipes:

• •No ambiguity: “Cook until done” is ambiguous; an algorithm must say what “done” means.
• •No missing steps: every step must be explicit enough to follow.
• •Works for all valid inputs: not just one example.

The three atomic concepts

This node is built from three atomic ideas:

1. 1)Procedure (ordered steps)

• •There is a first step, then a second, etc.
• •Order matters.

2. 2)Input (initial data)

• •The “stuff you start with.”
• •Could be numbers, text, images, a graph of roads, or even a stream of sensor readings.

3. 3)Output (result)

• •The “stuff you want at the end.”
• •Could be a number, a decision (yes/no), a sorted list, a route, or a compressed file.

What an algorithm is not

It helps to separate “algorithm” from nearby ideas:

A single algorithm can be implemented by many different programs (Python, Java, C++). And one program might contain multiple algorithms.

Key properties you should expect from an algorithm

Most of the time in computer science, when we say “algorithm,” we expect these properties:

1. 1)Definiteness (unambiguous steps)

• •Each step is precisely stated.

2. 2)Finiteness (termination)

• •It finishes after a finite number of steps.

3. 3)Correctness

• •For every valid input, it produces the intended output.

4. 4)Effectiveness (doable steps)

• •Each step is basic enough to be carried out (by a computer or by a person with the right tools).

You don’t need to prove all of these formally yet—but you should know what you’re aiming for.

Why focus on this “shape”?

If you can reliably identify input, process, and output, you can:

• •translate word problems into precise tasks,
• •test whether your solution makes sense,
• •compare two different approaches to the same problem.

This is the backbone of algorithmic thinking.

Input: what counts?

Input is any information the algorithm uses to do its job.

Examples:

• •A list of numbers: [3, 1, 4]
• •A name to search for: "Aisha"
• •A map (roads and distances)
• •A string: "racecar"

Sometimes input is empty (an algorithm might generate something, like the first 100 primes). Even then, you can think of the input as “the number 100” or “a stopping rule.”

Output: the contract

Output is the result you promise to deliver.

Examples:

• •The maximum number in a list
• •The position (index) where a name occurs, or “not found”
• •A route with minimal total distance
• •True/False for whether a string is a palindrome

A good habit: define output as a contract.

If the input satisfies X, the algorithm will output Y.

This mindset will later help you reason about correctness.

Process: steps that transform

The process is the ordered list of operations that turns input into output.

At a beginner level, most algorithm steps come from a small toolkit:

• •Assignment: set a variable (e.g., best ← 0)
• •Comparison: is a < b?
• •Iteration (loops): repeat steps for each item
• •Selection (if/else): choose a branch based on a condition

Example: “find the maximum” as input → output

Problem: Given a non-empty list of numbers, return the largest number.

• •Input: list L of length n ≥ 1
• •Output: max value in L
• •Process idea: scan through L, tracking the best seen so far

You can describe it in plain steps:

1. 1)Set best to the first element of L.
2. 2)For each remaining element x in L:

• •If x > best, set best ← x.

3. 3)Output best.

That is already an algorithm.

Why order matters

An algorithm is not just “a set of steps,” it’s an ordered sequence.

Consider these two instructions:

• •“Pour batter into pan”
• •“Preheat oven”

The order affects what happens. In computing, order is even stricter: doing something before a variable is initialized might crash a program or produce nonsense.

Algorithms can be deterministic or not

Many beginner algorithms are deterministic:

• •Same input → same output, every time.

Some algorithms use randomness (later you may see randomized algorithms), where:

• •Same input → output may vary, but still meets a goal (e.g., fast on average).

At this node, focus on deterministic algorithms; the input → output mapping is the cleanest.

A gentle mathematical view: algorithms as functions

You can think of an algorithm like a function f that maps inputs to outputs:

f(input) → output

For example, if input is a number n and output is n²:

f(n) = n²

But be careful: not every algorithm is “just a formula.” Many algorithms define f through a sequence of steps (like scanning a list) rather than a closed-form expression.

The arrow symbol →

You’ll see → used to mean “maps to” or “transforms into.”

• •Input → Output
• •State_before → State_after

Example: if we keep a variable best, one step might be:

(best, x) → (max(best, x))

You don’t need to write it this way all the time, but it captures the idea that each step transforms the current state into a new state.

Why these three?

Many “almost algorithms” fail because they are:

• •vague (not precise),
• •endless (don’t terminate), or
• •wrong on some inputs (not correct).

Learning to check these early saves a lot of time later.

1) Precision (unambiguous steps)

An algorithm must be clear enough that two different people (or computers) do the same thing.

Ambiguous instruction:

• •“Pick a large number from the list.”

Precise instruction:

• •“Return the maximum element of the list.”

Even more precise (when needed):

• •“If the list contains multiple equal maxima, returning that value is sufficient.”

Notice how precision often means defining edge cases.

2) Termination (it stops)

An algorithm should finish in a finite number of steps.

A loop like:

• •“Repeat forever”

is not an algorithm for a typical problem (unless the output is meant to be an ongoing stream).

A common way to ensure termination is to have a loop that makes measurable progress:

• •For each element in a finite list (you will eventually run out)
• •While i ≤ n, increase i by 1 each time

Example of a terminating loop

If i starts at 1 and you do i ← i + 1 until i = n, you will stop after n − 1 increments.

3) Correctness (it gives the right answer)

Correctness means: for every valid input, the output matches the problem’s definition.

At this stage, you can reason informally by asking:

• •Does it work on typical cases?
• •Does it work on edge cases?
• •Can I explain why it always works?

A mini “proof idea” using invariants (informal)

An invariant is a statement that stays true as your algorithm runs.

For the maximum-finding algorithm, an invariant could be:

• •After scanning the first k elements, best is the maximum of those k elements.

Why that helps:

• •Initially (k = 1), best is the maximum of the first element (trivially true).
• •Each step updates best to keep the statement true.
• •At the end (k = n), best is the maximum of the whole list.

You don’t need formal proof syntax yet. But this style of reasoning—maintaining a true statement while progressing—will become extremely powerful.

Algorithms vs. solutions that “seem to work”

If you test only a few inputs, you might miss failures.

Example: an incorrect algorithm for maximum might start with best ← 0. It works for lists of positive numbers but fails for lists like [-5, -2].

Correctness requires thinking beyond a few examples.

A note about data types (numbers vs. vectors)

Later you’ll see algorithms that operate on vectors like v ∈ ℝⁿ. For instance, an algorithm might take v as input and output ‖v‖ (its length).

Even though this node is foundational, the same input → process → output framing applies:

• •Input: v
• •Process: compute ∑ᵢ vᵢ², then take √
• •Output: ‖v‖ = √(∑ᵢ vᵢ²)

You don’t need vector math to understand what an algorithm is, but it shows that algorithms generalize far beyond lists of integers.

Why this connection matters

Once you can clearly describe an algorithm, the next natural question is:

How efficient is it?

Two algorithms can solve the same problem but take very different amounts of time as input size grows. Big O notation is the standard language for talking about that growth.

This node “unlocks” Big O because Big O is about algorithms specifically—their step counts, memory usage, and scaling behavior.

Step counting: the seed of complexity

Consider the maximum-finding algorithm on a list of length n.

• •It compares each element (after the first) once.
• •Number of comparisons is (n − 1).

So the work grows roughly proportionally to n.

That idea becomes:

• •Time complexity ≈ O(n)

Another example: checking if two lists are identical element-by-element also takes work proportional to n in the worst case.

Comparing two approaches (preview)

Suppose you want to find whether a number x is in a list of n numbers.

Approach A: scan from the beginning until you find x.

• •Worst case: x is not there → you check all n elements → O(n)

Approach B (if the list is sorted): use binary search.

• •Each step halves the remaining search space
• •Steps ≈ log₂(n) → O(log n)

At this node, you don’t need to master these algorithms yet; the key point is:

• •Big O compares algorithms based on how their step counts grow with input size.

What you need before Big O

To understand Big O well, you need the habits from this lesson:

• •Define input size (often n)
• •Describe the process (what operations repeat?)
• •Identify termination (how many steps until it stops?)

Once you can do that, you can translate “steps” into growth rates.

Where algorithms show up everywhere

Algorithms aren’t only for “classic CS problems.” They appear in:

• •Web search (ranking pages)
• •Maps (route planning)
• •Machine learning (training procedures)
• •Security (encryption and hashing)
• •Graphics (rendering and compression)

In all cases, the structure remains:

input → process → output

That’s why this node is foundational.