JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

What Is Computational Mathematics?

Meet the branch of mathematics that solves real problems with algorithms whose answers are deliberately, honestly approximate — and learn the two questions you will ask of every method: how wrong is it, and how much does it cost?

A different kind of answer

In the calculus and linear algebra you have already climbed, an answer was usually an exact expression: the integral equals pi/2, the system has the solution x = 3, the eigenvalue is exactly sqrt(2). Computational mathematics is the branch that asks a humbler, more practical question instead: given a real problem and a finite machine, how do we produce a number that is close enough, fast enough, and that we can trust? It is the home of numerical analysis, and its answers are almost always approximate — not because we are sloppy, but because the exact answer is either unreachable or unnecessary.

Think of the difference this way. Pure, symbolic mathematics is like an architect's perfect blueprint: a clean line for sqrt(2) that exists exactly on paper. Computational mathematics is the carpenter who must cut a real board to 1.41421356 metres, because no saw can cut an endless decimal. Both are doing mathematics; one works in the world of ideal objects, the other in the world of finite machines, finite time, and imperfect data. The carpenter is not failing at the architect's job — they are doing a job the architect cannot do at all.

The algorithm and its cost

The central object of this field is the algorithm: a finite, unambiguous recipe of steps that turns an input into an output. You met algorithms in pseudocode already; here they carry numbers, not just logic. A classic example is Newton's method for solving f(x) = 0. You guess a starting point x_0, then repeatedly improve it: each new guess is where the tangent line to f at the current guess crosses zero.

x_{n+1} = x_n - f(x_n)/f'(x_n)

guess x_0
repeat:
    x_{n+1} = x_n - f(x_n)/f'(x_n)
until |x_{n+1} - x_n| is tiny
Newton's method: a three-line loop that sharpens a guess for a root of f.

Once you have an algorithm, the second question is always: what does it cost? Cost is measured in the number of basic operations as the problem size n grows, written with big-O notation. Sorting n items might cost O(n log N); solving a dense linear system A x = b by Gaussian elimination costs about O(n^3); a fast Fourier transform turns an O(n^2) job into O(N log N), which is the kind of speed-up that changes what is possible. Doubling n that costs O(n^3) makes the work eight times larger — cost is not an afterthought, it decides whether your method finishes today or next year.

Where the wrongness comes from

If every answer is approximate, then understanding the gap between our number and the truth is the heart of the craft. That gap is the error, and it pours in from four distinct taps. The next four guides in this rung open each tap in turn, but it helps to see the whole plumbing first.

  1. Modeling error: the equations are already a simplification of reality. We model a real beam as a perfect line, or air as having no viscosity. The model is wrong before any computer touches it.
  2. Data error: the inputs are measured, and measurements carry noise. If your starting numbers are good to three digits, no algorithm can hand you ten trustworthy digits.
  3. Truncation error: we replace an infinite process with a finite one. We stop an infinite series after a few terms, or approximate a derivative by a finite difference. This is the error of O(h^p) you will meet again and again.
  4. Round-off error: the machine cannot store most real numbers exactly. It works in floating-point, keeping only about 16 decimal digits, and rounds at every single operation.

That last tap deserves a hard look, because it surprises everyone. The floating-point numbers in a computer are not the real numbers of your textbook. The friendly decimal 0.1 has no exact binary form, so 0.1 + 0.2 does not give exactly 0.3. Worse, floating-point addition is not associative: (a + b) + c can differ from a + (b + c). These are not bugs; they are the honest price of squeezing the infinite real line into 64 bits, and a good algorithm is designed to keep that price small.

Measuring the gap: absolute and relative

To talk about error precisely we need two rulers. The absolute error is the raw distance between the true value and the computed value — if the truth is 100 and we get 100.5, the absolute error is 0.5. The relative error divides that gap by the size of the true value — here 0.5/100, or 0.5 percent. Relative error is usually what we care about, because it tells us how many correct significant digits we have, regardless of scale. An error of 0.5 is tiny next to a million but catastrophic next to one.

Here is the deepest idea in this whole rung, and it deserves a slogan: accuracy = conditioning x stability. The condition number measures how sensitive the problem itself is — how much the answer wobbles when the input wobbles, no matter who solves it. Stability measures how much extra error your particular algorithm adds. A problem with a condition number near 10^8 will lose you about 8 of your roughly 16 double-precision digits before any algorithm even starts, simply because the problem amplifies input noise that hard. A perfectly stable algorithm still produces garbage on an ill-conditioned problem; that is the problem's fault, not the method's.

So what does a good algorithm even promise? Not the exact answer to your exact problem — that is often impossible. The realistic goal is backward stability: the algorithm returns the exact answer to a nearby problem, one whose input is within round-off of yours. If your problem is well-conditioned, a backward-stable method gives an answer you can trust; if it is ill-conditioned, it tells you the honest truth that no method could have done better. This is also why, in practice, you rarely solve A x = b by forming the matrix inverse — it is more expensive and less stable than factoring A directly.

Converging on the answer

Many numerical methods do not finish in one shot; they iterate, producing a sequence x_0, x_1, x_2, ... that you hope marches toward the true answer. The method converges if those guesses settle down to the truth as you take more steps. But two methods that both converge can do so at wildly different speeds, and the rate of convergence is how we grade that. Linear convergence wins a fixed fraction of the remaining error each step — think of always halving the gap. Quadratic convergence roughly squares the error each step, so the number of correct digits doubles per step: a blistering 2, 4, 8, 16 digits.

Newton's method is the poster child for quadratic convergence — but, and this is the honest fine print, only near a simple root, and only when you start close enough. Far from the root, or at a flat spot where f'(x) is near zero, Newton's method can overshoot wildly, diverge, or even cycle forever between two points. "Fast when it works" is not the same as "always works," and a recurring lesson of this whole field is that every method comes with a fence around the cases where it behaves.

Convergence also has a second meaning you will use constantly: as you shrink a step size h — the spacing in a finite difference, the width of an integration panel — the truncation error shrinks like O(h^p), where the exponent p is the order of accuracy. A second-order method, O(h^2), cuts its error fourfold when you halve h. It is tempting to think ever-smaller h means ever-better answers, but that is a trap: shrink h too far and round-off error takes over, putting a floor under how accurate you can get. There is a sweet spot, and finding it is exactly the balance between truncation and round-off you just met.