What is an Algorithm - Algorithms — Core Concepts | OneNoughtOne

0/361

Data Structures & AlgorithmsAlgorithms — Core Concepts

Algorithms — Core Concepts

LevelBeginner

Duration50 mins

TopicAlgorithms — Core Concepts

1 / 4

What is an Algorithm

The Ubiquitous Algorithm

The word algorithm appears everywhere in modern discourse—in headlines about artificial intelligence, in debates about social media curation, in discussions about autonomous vehicles and financial trading systems. Politicians invoke algorithms when discussing tech regulation. Journalists cite algorithms when explaining recommendation systems. Yet beneath this ubiquitous usage lies a remarkably precise concept, one that predates electronic computers by centuries and underpins every computational system ever built.

An algorithm is not merely 'code that does something.' It is a fundamentally different concept—older, deeper, and more universal than any programming language or computing device. Understanding what an algorithm truly is, at its core, transforms how you approach problem-solving in computer science and beyond.

What You Will Learn

By the end of this page, you will understand the precise definition of an algorithm, trace its historical origins, recognize the essential properties that distinguish algorithms from other problem-solving approaches, and appreciate why this abstraction is the foundation of all computer science.

Etymology and Historical Origins

The word algorithm derives from al-Khwarizmi, the name of a 9th-century Persian mathematician named Muḥammad ibn Mūsā al-Khwārizmī. Working at the House of Wisdom in Baghdad, al-Khwarizmi composed influential texts on algebra and arithmetic that, when translated into Latin, introduced systematic mathematical procedures to medieval Europe.

The Latinized rendering of his name—Algoritmi—came to denote the step-by-step methods he described. Over centuries, algorithm evolved to mean any well-defined computational procedure.

But algorithms predate even al-Khwarizmi by millennia:

Historical Algorithms Through the Ages
Era	Algorithm	Description	Significance
~300 BCE	Euclid's Algorithm	Finds the greatest common divisor (GCD) of two integers through repeated division	One of the oldest known algorithms still in use today
~250 BCE	Sieve of Eratosthenes	Identifies all prime numbers up to a given limit by systematic elimination	Early example of algorithmic efficiency analysis
9th Century	Al-Khwarizmi's Procedures	Step-by-step arithmetic methods including solving linear equations	Gave rise to the word 'algorithm'
17th Century	Newton-Raphson Method	Iteratively approximates roots of real-valued functions	Foundation for numerical analysis
1936	Turing Machine	Abstract mathematical model defining computation itself	Formalized what algorithms can and cannot compute

The key insight: Algorithms existed long before computers. Ancient mathematicians understood that complex problems could be solved through systematic, repeatable sequences of operations. A trained human could execute these procedures reliably without creativity or insight—only careful adherence to explicit instructions.

This insight—that mechanical execution of formal steps can solve problems—is the conceptual foundation on which all of computer science is built.

Algorithms Are Language-Independent

Euclid described his algorithm in ancient Greek prose. Al-Khwarizmi wrote in Arabic. Turing used mathematical notation. Modern developers use Python, Java, or Rust. The algorithm itself—the abstract procedure—remains unchanged across all these representations. This language-independence is fundamental to understanding what algorithms truly are.

The Formal Definition

While informal descriptions abound, a rigorous understanding of algorithms requires precision. Here is a formal definition that captures the essential properties:

Definition: Algorithm

An algorithm is a finite sequence of well-defined, unambiguous instructions that, given some input, produces a corresponding output, accomplishing a specific computational task. The algorithm terminates after a finite number of steps and produces the same output for identical inputs.

Let's dissect this definition carefully, as every word carries meaning:

Finite sequence — An algorithm must have a definite number of steps. It cannot go on forever. An 'algorithm' that runs indefinitely for certain inputs is, by definition, not an algorithm—it's an unbounded procedure.

Well-defined — Each step must be precisely specified, leaving no room for interpretation. If two people can follow the same step and arrive at different results, the step is not well-defined.

Unambiguous — There must be exactly one interpretation of each instruction. Phrases like 'repeat a lot' or 'make it faster' are ambiguous. 'Repeat 10 times' or 'double the value' are unambiguous.

Input and Output — An algorithm operates on data (input) and produces a result (output). The input may be empty (zero values), but the relationship between input and output must be well-specified.

Specific task — An algorithm solves a particular, well-defined problem. Sorting, searching, calculating GCD, finding shortest paths—these are computational tasks with clear success criteria.

Terminates — For valid inputs, the algorithm must eventually stop. This is the halting property. An endless loop means the procedure fails to be an algorithm.

Deterministic — Given the same input, a (classical) algorithm produces the same output every time. This reproducibility is essential for correctness verification.

Essential Properties of Algorithms

•Finiteness — Must terminate after a finite number of steps
•Definiteness — Each step must be precisely defined and unambiguous
•Input — Zero or more inputs are taken from a specified set
•Output — One or more outputs are produced, related to inputs
•Effectiveness — Every step must be basic enough to be executable
•Generality — Applies to a class of problems, not just one instance

What Algorithms Are NOT

Understanding what algorithms are becomes sharper when we clarify what they are not. Many things that seem algorithmic fail to meet the formal definition:

NOT Algorithms

•Vague recipes — 'Add salt to taste' is ambiguous and subjective
•Infinite loops — Procedures that never halt for some inputs
•Heuristics — Rules of thumb that usually work but lack guarantees
•Random guesses — Trial without systematic structure
•Human intuition — Creative leaps that can't be mechanically replicated
•Physical processes — Mixing chemicals follows laws of nature, not specified steps

ARE Algorithms

•Precise recipes — 'Add exactly 5 grams of salt' is unambiguous
•Guaranteed termination — Finite steps with proven bounds
•Deterministic procedures — Same input always yields same output
•Systematic search — Exhaustive or structured exploration
•Formal methods — Mechanically verifiable steps
•Mathematical procedures — Long division, polynomial multiplication

The Heuristic Trap

Many 'algorithms' in popular usage are actually heuristics—methods that work well in practice but lack formal guarantees. A spell-checker's suggestion system, a traffic jam avoidance heuristic, or a recommendation engine's scoring function may appear algorithmic but often incorporate probabilistic elements, learned behaviors, or approximations that deviate from the strict definition. In computer science, we maintain this distinction carefully.

The Halting Problem Reminder:

Alan Turing proved in 1936 that there is no general algorithm that can determine, for every possible program-input pair, whether the program will eventually halt or run forever. This means we cannot always mechanically verify whether a given procedure is truly an algorithm (in the terminating sense) without running it.

This is not a practical obstacle for most algorithms we write—we design them with termination guarantees built in (loop bounds, decreasing measures, etc.). But it's a fundamental theoretical result that shapes our understanding of computability.

Abstract vs Concrete Representations

A critical insight separates novice programmers from experienced computer scientists: the algorithm is distinct from its representation.

Consider binary search—an algorithm for finding a target value in a sorted array by repeatedly halving the search space. Binary search exists as an abstract concept, describable in plain English:

Compare the target to the middle element.
If they're equal, you've found it.
If the target is less, search the left half.
If the target is greater, search the right half.
Repeat until found or the range is empty.

This same algorithm can be expressed in:

binary_search.pseudo

Pseudocode

BINARY-SEARCH(A, target)
    left ← 0
    right ← length(A) - 1
    
    WHILE left ≤ right DO
        mid ← ⌊(left + right) / 2⌋
        
        IF A[mid] = target THEN
            RETURN mid
        ELSE IF A[mid] < target THEN
            left ← mid + 1
        ELSE
            right ← mid - 1
        END IF
    END WHILE
    
    RETURN -1  // Not found

The profound implication:

The algorithm (binary search) is unchanged across all these representations. The abstract procedure—halving the search space repeatedly—is independent of syntax, language features, or runtime environment.

This is why we can analyze algorithms mathematically without specifying a language. When we say 'binary search runs in O(log n) time,' this statement holds whether the algorithm is implemented in JavaScript, Rust, assembly language, or executed by a human with paper and pencil.

Separating abstraction from implementation is one of the most powerful mental skills in computer science. It allows us to reason about correctness and efficiency at the conceptual level, then implement in any suitable medium.

Think in Algorithms, Code in Languages

Experienced engineers don't think in Python or Java when solving problems—they think in algorithms and data structures. The language is merely a tool for expressing the solution. Master the abstractions first; language proficiency follows naturally.

The Algorithm as Problem-Solution Mapping

Another perspective on algorithms views them as mappings from problems to solutions—more precisely, from problem instances (inputs) to correct answers (outputs).

Consider the sorting problem:

Problem: Arrange a sequence of comparable elements in non-decreasing order.
Instance: [3, 1, 4, 1, 5, 9, 2, 6]
Solution: [1, 1, 2, 3, 4, 5, 6, 9]

A sorting algorithm is a procedure that correctly produces the solution for every valid problem instance—not just one specific input, but all possible inputs within the problem's domain.

Algorithms as Input-Output Mappings
Problem	Input Domain	Output Domain	Example Algorithms
Sorting	Any sequence of comparable elements	Same elements in sorted order	Merge Sort, Quick Sort, Heap Sort
Searching	Sorted array + target value	Index of target or 'not found'	Binary Search, Interpolation Search
Shortest Path	Weighted graph + source + destination	Minimum-cost path or distance	Dijkstra's, Bellman-Ford, A*
Pattern Matching	Text + pattern string	All positions where pattern occurs	KMP, Rabin-Karp, Boyer-Moore
Factorization	Positive integer n	Prime factors of n	Trial Division, Pollard's rho

The generality requirement:

An algorithm must work for all inputs in its domain, not just specific test cases. A procedure that correctly sorts [3, 1, 2] but fails on [5, 4, 3, 2, 1] is not a correct sorting algorithm—it's a partial solution that doesn't satisfy the problem specification.

This is why algorithm correctness proofs are essential. They demonstrate that the procedure works for every possible input, not just the examples we've tested. Without such proofs (formal or intuitive), we cannot trust the algorithm.

Problems vs Problem Instances

In algorithm design, we distinguish between a problem (a general question parameterized by inputs) and a problem instance (a specific input). 'Sort an array' is a problem. 'Sort [3,1,2]' is an instance. Algorithms solve problems; they produce answers for all valid instances.

Why This Definition Matters

You might wonder: why spend so much time on definitions? Can't we just write code and see if it works?

The formal definition of algorithms matters for several profound reasons:

Why Precision Matters

•Correctness Verification — We can only prove an algorithm correct if we know precisely what an algorithm is. Informal definitions lead to informal (often wrong) conclusions.
•Complexity Analysis — Mathematical analysis of time and space requires that algorithms be well-defined. Ambiguous steps can't be assigned precise costs.
•Comparison and Selection — Knowing multiple algorithms solve the same problem, we need rigorous methods to compare them. This requires formal definitions.
•Communication — Engineers across companies, languages, and decades can collaborate because 'algorithm' has a shared, precise meaning.
•Theoretical Foundations — Computability theory—understanding what problems can and cannot be solved algorithmically—depends entirely on formal definitions.
•Automation — Compilers, interpreters, and optimization tools rely on algorithms being formally specified; ambiguity would make compilation impossible.

The professional distinction:

Junior developers often think in terms of 'code that works for my test cases.' Senior engineers think in terms of algorithms that are provably correct for all valid inputs. This shift—from empirical testing to formal reasoning—is what separates coding from computer science.

That doesn't mean you must write formal proofs for every function. But internalizing what an algorithm is changes how you design, debug, and evaluate solutions. You start asking: 'Will this terminate?' 'Is every step well-defined?' 'What inputs could break this?'—questions that prevent bugs before they occur.

Euclid's Algorithm — A Complete Example

To solidify our understanding, let's examine one of the oldest and most elegant algorithms in mathematics: Euclid's algorithm for computing the greatest common divisor (GCD).

Problem: Given two positive integers a and b, find their greatest common divisor—the largest integer that divides both without remainder.

The Algorithm (as Euclid described it ~300 BCE):

If b = 0, the GCD is a. Otherwise, the GCD of a and b equals the GCD of b and (a mod b). Repeat until b becomes 0.

euclid_gcd.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
def gcd(a: int, b: int) -> int:
    """
    Compute the greatest common divisor using Euclid's algorithm.
    
    Precondition: a >= 0 and b >= 0, at least one is positive.
    """
    while b != 0:
        a, b = b, a % b
    return a
 
 
# Example execution trace:
# gcd(48, 18)
#   a=48, b=18 → a=18, b=48%18=12
#   a=18, b=12 → a=12, b=18%12=6
#   a=12, b=6  → a=6,  b=12%6=0
#   a=6,  b=0  → return 6
#
# GCD(48, 18) = 6  ✓

Let's verify this is truly an algorithm:

Checking the Essential Properties

•Finiteness — The value of b strictly decreases toward 0 with each iteration (since a mod b < b). Therefore, the loop must eventually terminate.
•Definiteness — Each step is precisely defined: compare b to 0, compute the modulo, assign values.
•Input — Two non-negative integers a and b from a well-defined domain.
•Output — A single integer representing the GCD.
•Effectiveness — Comparison and modulo are basic arithmetic operations executable in finite time.
•Correctness — Provable via the mathematical identity: gcd(a, b) = gcd(b, a mod b), with base case gcd(a, 0) = a.

Timeless Elegance

Euclid's algorithm has been in continuous use for over 2,300 years. It runs in O(log(min(a,b))) time—extraordinarily efficient. Every cryptographic system you use today (TLS, SSH, digital signatures) relies on variants of this ancient algorithm. The definition of 'algorithm' hasn't changed; the applications keep growing.

Summary: What is an Algorithm

We have established the foundational understanding of what an algorithm truly is—not merely 'code' or 'a set of instructions,' but a precisely defined abstract concept with deep historical roots and rigorous properties.

Key Takeaways

•Algorithms predate computers — They originated in ancient mathematics as systematic problem-solving procedures executable by humans.
•The formal definition is precise — Finite, well-defined, unambiguous steps that terminate and produce correct output for all valid inputs.
•Essential properties include finiteness, definiteness, input/output, effectiveness, and generality — Missing any property disqualifies a procedure as an algorithm.
•Algorithms are abstract, language-independent — The same algorithm can be expressed in pseudocode, Python, assembly, or plain English.
•Algorithms map problem instances to solutions — They don't solve one input; they solve all inputs in the problem's domain.
•This precision enables correctness proofs, complexity analysis, and rigorous comparison — Without formal definitions, computer science would lack foundations.

What's Next:

Now that we understand what an algorithm is, the next page explores what makes an algorithm good. Not all algorithms are equal—some are correct but slow, others fast but unclear. We'll examine the four pillars of algorithm quality: correctness, efficiency, clarity, and scalability.

Page Complete

You now possess a rigorous understanding of what algorithms are—a foundation that will support every concept to come. Remember: mastering definitions isn't pedantic; it's the prerequisite for precise thinking in computer science.