In the previous section, we saw that floating-point inputs carry small relative errors bounded by machine epsilon, and that subtracting nearly equal numbers amplifies those errors catastrophically. The condition number makes this precise — and applies to any computation, not just subtraction.
Condition of at ¶
When we evaluate but only have an approximation to the input, the output may be far from . The condition number is the worst-case ratio of relative error in the output to relative error in the input.
Simplified Formula via Taylor’s Theorem¶
Condition Number of a Differentiable Function¶
For a differentiable function , we can derive the condition number formula directly from the definition of relative error, without appealing to Taylor’s theorem.
Absolute Condition Number¶
The absolute condition number measures the ratio of absolute error in the output to absolute error in the input:
If is large, a small absolute change in produces a large absolute change in .
Derivation from Relative Errors¶
Starting from Definition 1, suppose is perturbed by a small amount . The relative change in is , while the relative change in the output is . Taking the ratio:
The last factor is a difference quotient. In the limit it becomes , recovering the formula from Proposition 1.
The formula can be read as the ratio of the logarithmic derivative of to the logarithmic derivative of :
This makes intuitive sense: the logarithmic derivative measures the infinitesimal rate of relative change, so the condition number is the ratio of the relative rate of change of the output to that of the input.
Note that if has a zero at , then . This is not necessarily because the computation is genuinely sensitive. The absolute error may be perfectly well-behaved, but relative error is undefined at a zero of .
Several Variables¶
For a differentiable map , the relative condition number generalises to
where is the Jacobian matrix of at and denotes the induced matrix norm. The one-variable formula is the special case .
Examples¶
Example 1 (Square Root (Well-Conditioned))
Example 2 (Tangent Near π/2 (Ill-Conditioned))
Example 3 (Logarithm Near 1 (Ill-Conditioned))
Consider near .
As , we have , so .
Result: — evaluating near is ill-conditioned.
But note why this happens: the condition number blows up because , so the relative error has a denominator going to zero. The absolute error is perfectly well-behaved — , so a small input perturbation produces a small absolute output perturbation. The “ill-conditioning” here is really that relative error is undefined at a zero of . This happens for any function near one of its roots, and is an artifact of measuring error in relative terms rather than a genuine sensitivity of the computation.
Condition Number of Subtraction¶
The condition number formula works for functions of one variable. For a function of two variables , we generalize: the condition number measures how the relative error in relates to the relative errors in and .
Example 4 (Subtraction is Ill-Conditioned When )
Consider with small perturbations and :
The relative error in the result is:
The condition number of subtraction is therefore:
When and are well-separated: — subtraction is well-conditioned.
When : — subtraction is ill-conditioned.
This is precisely the catastrophic cancellation we saw in the floating-point chapter, now explained through the lens of condition numbers.
Condition Number of the Finite Difference¶
We can now give a condition number explanation of the finite difference trade-off.
Example 5 (Finite Difference Condition Number)
The forward difference requires computing where and .
Applying the subtraction condition number with :
As , this condition number grows like . Each input carries relative error (machine epsilon), so the round-off contribution to the finite difference is:
This matches exactly the round-off term we derived from the floating-point analysis — but now we see it as a conditioning problem: the subtraction step is ill-conditioned for small .
Summary¶
The condition number measures how much a problem amplifies input errors. It is a property of the mathematical problem, not the algorithm — if is large, no algorithm can avoid accuracy loss. But what if is small and we still get poor results? Then the problem isn’t to blame — the algorithm is. In the next section, we make this precise with the concept of stable and unstable algorithms.