the conditioning of a problem

Imagine you weigh out a recipe but your kitchen scale is off by a gram. For a stew, nobody notices. For a delicate meringue, that one gram ruins it. The recipe itself decides how forgiving it is to a small slip in the input. Conditioning is exactly this idea for a mathematical problem: how much the answer moves when the data you feed in wobble a little.

Be careful about what conditioning is attached to. It is a property of the PROBLEM (the map from input to output), not of any algorithm you use to solve it. Formally, a problem takes some input x and produces an output f(x). If a tiny relative change in x — say replacing x by x plus delta-x — forces only a tiny relative change in f(x), the problem is well-conditioned. If a tiny change in x can produce a wildly different f(x), the problem is ill-conditioned. The number that measures this sensitivity is the condition number; the smaller it is, the better.

This matters because conditioning sets a hard floor on accuracy that no clever programming can beat. Your inputs are almost never exact: they come from measurements, or from rounding a real number into floating-point. If the problem itself amplifies those unavoidable input errors by a factor of, say, a million, then your answer carries at least that million-fold error baked in — and that is the problem's fault, not your code's. Distinguishing 'the problem is intrinsically hard' from 'my algorithm is bad' is the first move in reliable computing.