You ran a small army of algorithms this morning and not one of them asked for credit. The satnav that picked your route. The bank that cleared your card while you queued for coffee. The feed that put that one clip in front of you. Same machine underneath every time: a finite list of exact steps, run in order, on data you handed over without a second thought.
An algorithm is an ordered, finite set of precise instructions that run step by step to solve a problem or finish a task. It takes zero or more inputs, works them with rules that leave no room for ambiguity and hands back one or more outputs. Hold that definition against the world and it fits a cooking recipe, the route a satnav calculates and the system that decides which post a social network shows you first.
The word was born in mathematics, and today it carries almost all of computing on its back. Here is where this piece goes, so you can jump to the part you need: where the term comes from, the properties an algorithm must meet, how you sketch one with pseudocode and flowcharts, the classic search and sorting examples with their cost in Big O notation, where algorithms live in your daily routine and what part they play in artificial intelligence.
What is an algorithm: definition and origin
Start with a name, because the word comes straight from a person. «Algorithm» is the Latinised name of Muhammad ibn Musa al-Khwarizmi, a Persian mathematician of the ninth century. His treatises on algebra and arithmetic carried the Indo-Arabic numeral system into Europe, and they carried something else with them: a way of calculating with digits that you could write down and repeat. «Algoritmi», the Latin shape of his name, ended up meaning a method of calculation and, from there, any systematic procedure for computing. The biography and the etymology sit in the mathematical archive of the University of St Andrews.
Computer science wants a tighter definition. The NIST dictionary of algorithms and data structures calls it «a well-defined computational procedure that takes some value, or set of values, as input and produces some value, or set of values, as output» (Dictionary of Algorithms and Data Structures). Donald Knuth, in The Art of Computer Programming, pins down the five features that separate an algorithm from a vague plan: finiteness, definiteness, input, output and effectiveness. Those five words earn their place, so take them one at a time.
The properties of an algorithm
For a procedure to count as an algorithm rather than an idea you are still chewing on, it has to meet these conditions:
| Property | What it means |
|---|---|
| Finiteness | It ends after a finite number of steps. A process that never finishes is a procedure missing the guarantee this rule demands. |
| Definiteness | Every step is specified without ambiguity: in the same state, the algorithm always behaves the same way. |
| Input | It receives zero or more pieces of data from outside before it starts. |
| Output | It produces one or more results, tied to the input it received. |
| Effectiveness | Each operation is basic enough to be carried out in finite time, by hand or by a machine. |
| Generality | It solves a whole class of problems, and it works for any single case inside that class. |
Finiteness deserves its own paragraph, because it draws the line between what a machine can solve and what it cannot. An algorithm has to promise that it stops. If a problem admits no solution that always terminates, you are looking at an undecidable problem, not at an algorithm with a bug in it. Definiteness matters just as much the moment you write real code. «Sort the list sensibly» is useless to a machine. «Compare each pair of adjacent items and swap them if they are out of order» runs without a second thought, because every step is nailed down and the result is the same every time.
How an algorithm is represented
An algorithm is an idea, and an idea can be written in more than one way. Long before you type a line of a programming language, you describe it with tools that do not depend on code. That way you can review it, compare it against another option and fix it without a compiler shouting at you about a missing bracket.
Pseudocode
Pseudocode mixes plain language with programming structures. No machine runs it, yet anyone with the basics reads it in a single pass. Say you want the largest value in a list. Here is the whole thing:
function maximum(list)
largest = list[0]
for each value in list do
if value is greater than largest then
largest = value
end if
end for
return largest
end functionThe value of pseudocode is what it forces out of you. What happens if the list is empty? Where does the loop stop? Writing it down in this half language settles those questions before they turn into a bug you spend an afternoon chasing. It is the usual middle step between framing the problem and building it.
Flowcharts
A flowchart draws the algorithm with symbols: ovals for the start and the end, rectangles for operations, diamonds for decisions and arrows for the order of execution. Its advantage is that you see it. Branches jump out at you, loops stop hiding and every path the program can take is on the page. As the algorithm grows, the chart becomes a tree of routes, which is exactly how you catch the branch nobody thought about and the condition that can never be reached.
From pseudocode to a programming language
The last move is to translate the description into a programming language, the bridge between the instructions a person understands and the ones a machine can run. A program is nothing more than a set of algorithms written in that language and wired together. The same algorithm shows up in wildly different clothes depending on the language, while the reasoning underneath stays identical: the steps, the conditions and the goal do not move.
Classic examples: search and sorting
Two families fill almost every textbook: search algorithms, which find a piece of data inside a collection, and sorting algorithms, which put that data in order. Learn them and you hold the doorway to the idea that decides everything later, complexity.
Search algorithms
Linear search walks the list element by element until it lands on what it wants. It is simple and it works on unsorted data, but in the worst case it inspects all n items. Binary search demands an ordered list and pays you back for it. It checks the middle element and throws away half of what is left at every step, so a list of a million items falls in about twenty comparisons. That gap is no detail. It is the difference between a search that finishes while you blink and one that keeps you waiting. The documentation of Python and of any standard library reflects the same principle: sort once and every search afterwards is cheap.
Sorting algorithms
Bubble sort compares adjacent pairs and swaps them until the list settles. Easy to explain, brutal on large lists. Quicksort picks a reference element, the pivot, splits the smaller items to one side and the larger to the other and repeats on each half. Fast in practice. Mergesort cuts the list in half, sorts each part and stitches them back together. More predictable, and stable. Each one follows a different strategy, swapping or divide and conquer, toward the same result. That word «stable» earns its keep: a stable sort keeps equal elements in their original relative order, which is what you want when you sort records by one field and refuse to scramble the order another field already set.
Complexity and Big O notation
Complexity describes how the work of an algorithm grows when the input grows. Big O notation writes that growth down for the worst case and lets you compare two algorithms without caring which machine runs them. This is why, past a certain size, the choice of algorithm beats the raw power of the hardware every time.
Complexity usually splits into two measures. Time complexity tracks how the number of operations climbs with the input. Space complexity tracks how much extra memory the algorithm needs to get the job done. The two trade off against each other. A cache spends memory to buy time, and a streaming algorithm saves memory by never holding the whole dataset at once. The right balance depends on what the machine in front of you is short of.
| Notation | Name | Typical example |
|---|---|---|
| O(1) | Constant | Accessing an array element by its index |
| O(log n) | Logarithmic | Binary search over sorted data |
| O(n) | Linear | Walking a list once, as in linear search |
| O(n log n) | Linearithmic | Efficient sorts such as mergesort or quicksort |
| O(n²) | Quadratic | Bubble sort, comparing every pair of elements |
The distance between O(n) and O(n²) is not academic. The same calculation that takes a second with a thousand items can take hours with a million. When a program turns slow as it swallows more data, the culprit is usually the algorithm, and the hardware only carries part of the blame. It is one of the common reasons a computer runs slow on certain jobs.
Algorithms in everyday life
Algorithms left the laboratory decades ago. Without a single notification, they pick what you see, what you buy and which way you drive.
Search and recommendation
Search for anything on Google and the order of the results comes from a set of ranking algorithms. The best known is PageRank, described by Sergey Brin and Larry Page in their founding 1998 paper (The Anatomy of a Large-Scale Hypertextual Web Search Engine), which scores a page by the links it receives from other relevant pages. In parallel, the feed of a social network and the catalogue of a video platform run recommendation algorithms that order content by what you did before. You never typed a query for that order. You produced it with every click.
Routes, logistics and markets
A satnav is solving a shortest-path problem over a graph of roads. The classic algorithm for it came from Edsger W. Dijkstra in 1959 (A note on two problems in connexion with graphs), and it is still the base of network routing and delivery planning today. In financial markets, high-frequency trading algorithms fire orders automatically the moment market conditions change, on timescales no human trader can follow. The route in your phone and the trade on the exchange come from the same family of ideas.
Operating systems and networks
Inside the machine, process scheduling shares CPU time among the programs you have open: the Round Robin algorithm hands each process a slice of time and rotates. Cache memory relies on replacement algorithms to decide which data to keep and which to throw away, and networks lean on routing algorithms to find the best path between two points. All of it traces back to the history of computing, where the design of procedures came before the first electronic computers ever switched on.
The role of algorithms in artificial intelligence
Artificial intelligence is no exception. To a large degree it is applied algorithmics. Machine learning models are built by training an algorithm on huge volumes of data so it tunes its parameters and cuts the error. Gradient descent and its variants are the optimisation method that makes that tuning possible, and backpropagation works out how each layer of a neural network should be corrected.
In recent years the transformer architecture, described in the paper Attention Is All You Need (Vaswani et al., 2017), and its attention mechanisms have pushed language and image-generation models forward. Behind all of them sit older algorithms too: search, sorting and optimisation running millions of times during training and inference. That is why the NIST AI Risk Management Framework keeps insisting that you document how these systems are designed and validated. Understanding the algorithm is the first condition for auditing it. The question of how to program ethics into a machine is old as well: the three laws of robotics that Isaac Asimov imagined in 1942 are still the most famous thought experiment on the subject.
Conclusion
An algorithm is a formal recipe: ordered, finite, unambiguous instructions that turn an input into an output. Its properties, finiteness, definiteness, input, output, effectiveness and generality, drew the boundary of the computable long before computers existed. You write it in pseudocode, you test it on a flowchart, you judge it by its complexity, and it holds up everything from an internet search to process scheduling, network routing and machine learning.
Understanding what they are and how they are measured pays off in decisions. Choosing the right algorithm can matter more than changing machines, and knowing what sits behind an AI system is the first step to using it and auditing it without blind trust. Pick the next boring task on your desk, write the steps down in order and check where it can fail. That is how you start thinking like the machine, and that habit is worth more than any new laptop.
Frequently asked questions
Are an algorithm and a program the same thing?
No. The algorithm is the abstract description of the procedure, the steps and their order. The program is that algorithm written in a concrete language and ready to run. The same algorithm turns into many different programs depending on the language and the style of the programmer.
Does every algorithm have to terminate?
Yes. Finiteness is one of its properties. A procedure that does not guarantee it will finish is an indefinite process. Some problems admit no solution that always terminates, and those are undecidable. In that case no algorithm exists for that problem. The implementation was never the missing piece.
What does Big O notation mean?
It describes how the time or space an algorithm consumes grows when the size of the input grows, focusing on the worst case and the dominant term. It lets you compare algorithms without thinking about the computer: an O(n log n) solution beats an O(n²) one the moment the data gets large enough.
Are AI algorithms different from classic ones?
They share the same foundations and add optimisation and learning on top. An AI model is still a sequence of finite, defined operations. What changes is that its parameters tune themselves from data instead of being set by hand. Underneath, the same old searches, sorts and mathematical operations keep doing the work.
Sources
- NIST: Dictionary of Algorithms and Data Structures
- Cormen, Leiserson, Rivest and Stein: Introduction to Algorithms (MIT Press)
- Knuth: The Art of Computer Programming (Vol. 1)
- Brin and Page: The Anatomy of a Large-Scale Hypertextual Web Search Engine (1998)
- Dijkstra: A note on two problems in connexion with graphs (1959)
- Python: Sorting HOW TO (official documentation)
- NIST: AI Risk Management Framework (AI RMF 1.0)