Numerical Stability and Conditioning

A correct algorithm can still give a wrong answer if the problem is ill-conditioned or the scheme is unstable; we check for both.

Correct math, wrong number

Even a verified algorithm can produce a wrong result if the problem is poorly conditioned or the numerical scheme is unstable. Conditioning measures how much the answer amplifies small input errors; stability measures whether errors grow as a computation proceeds. Both can turn a mathematically correct method into a source of nonsense, so we check them explicitly.

Conditioning: sensitivity built into the problem

An ill-conditioned problem amplifies tiny input or round-off errors into large output errors, no matter how good the algorithm. We estimate conditioning, and where it is poor we either reformulate the problem or carry extra precision and report the residual sensitivity. Pretending a well-behaved algorithm rescues an ill-conditioned problem is a mistake we design against.

Stability: errors that grow

An unstable scheme lets small errors compound until the solution is garbage, sometimes while still looking plausible for a while. We choose schemes with known stability properties for the regime, respect their limits (timestep bounds, for instance), and watch for the signatures of instability rather than trusting a run that finished without crashing.

Stability and conditioning are why 'the code ran and produced a number' is never sufficient. A number can be the smooth output of an unstable computation. The standard is to show the computation was well-conditioned and stable, so the clean-looking result is clean for the right reasons. Checking conditioning and stability is therefore not a separate specialty bolted onto the analysis; it is part of what it means to claim a computed number at all, because without it 'the code produced this value' and 'this value is right' are two different statements.