Why Reuse the Past Instead of Resampling the Present
Everything in this rung has been about the same task: marching a solution of the numerical initial value problem y' = f(x, y) forward one step at a time. Euler's method used a single slope at the start of each step; the Runge-Kutta methods you just met buy higher accuracy by evaluating f several times *within* each step, sampling the slope at cleverly chosen interior points before committing. RK4, for instance, calls f four times per step. That works beautifully — but notice the quiet waste: at the end of a step those four evaluations are discarded, and the next step starts its sampling all over again.
A multistep method asks a thrifty question: what if, instead of resampling the slope fresh inside every step, we reuse the slope values f we *already* computed at the last few grid points? After all, by the time we want to step from x_n to x_(n+1), we are sitting on a small archive — the recent solution values y_n, y_(n-1), y_(n-2), ... and their slopes f_n, f_(n-1), f_(n-2), .... A multistep method fits a polynomial through that recent history of slopes and uses it to leap forward, so each new step costs roughly *one* fresh evaluation of f rather than four. The name says it: a single-step method like Runge-Kutta needs only the current point to take a step; a multistep method leans on several past points.
Adams-Bashforth: An Explicit Step from the Past
Here is the idea made concrete. Integrate y' = f(x, y) exactly over one step, from x_n to x_(n+1): the change in y is the integral of f over that interval. We cannot do that integral exactly — f depends on the unknown solution — so we *approximate the integrand f* by a polynomial that passes through the slope values we already know at recent points, then integrate that polynomial instead, which is easy. If we fit through f_n alone (a flat line), we recover plain Euler. Fit a straight line through f_n and f_(n-1) and integrate it, and out pops the two-step [[adams-bashforth-method|Adams-Bashforth method]]: y_(n+1) = y_n + (h/2)(3 f_n - f_(n-1)).
Look closely at that formula: the right-hand side uses only quantities you already have — f_n and f_(n-1) are slopes at points you have already passed. Nothing on the right depends on the unknown y_(n+1). That makes Adams-Bashforth an [[explicit-versus-implicit-method|explicit method]]: you simply plug in and compute the answer directly, no equation to solve. The price of accuracy is just memory — keep the last couple of f-values around. Adding more past points raises the order of the method: the popular four-step Adams-Bashforth fits a cubic through f_n, f_(n-1), f_(n-2), f_(n-3) and reaches fourth order, matching RK4's accuracy while calling f only once per step instead of four times.
Exact over one step: y(x_{n+1}) = y_n + integral_{x_n}^{x_{n+1}} f(x, y) dx
Approximate f by a polynomial through KNOWN past slopes, then integrate it:
AB1 (Euler) : y_{n+1} = y_n + h * f_n
AB2 : y_{n+1} = y_n + (h/2) * ( 3 f_n - f_{n-1} )
AB3 : y_{n+1} = y_n + (h/12) * ( 23 f_n - 16 f_{n-1} + 5 f_{n-2} )
AB4 : y_{n+1} = y_n + (h/24) * ( 55 f_n - 59 f_{n-1} + 37 f_{n-2} - 9 f_{n-3} )
where f_k = f(x_k, y_k) are slopes you ALREADY computed
EXPLICIT: the right-hand side never mentions y_{n+1} -> just plug in.Adams-Moulton: The Implicit Cousin That Peeks Ahead
Now allow one extra, slightly cheeky move. When we fit a polynomial through the slopes to approximate that integral, why restrict ourselves to *past* points? If we also let the polynomial pass through the slope at the very point we are stepping to — the not-yet-known f_(n+1) = f(x_(n+1), y_(n+1)) — the fit straddles the interval we are integrating over instead of extrapolating off its end, and that is genuinely more accurate. This gives the [[adams-moulton-method|Adams-Moulton method]]. The two-step version is y_(n+1) = y_n + (h/12)(5 f_(n+1) + 8 f_n - f_(n-1)).
But spot the catch staring out of that formula: f_(n+1) means f evaluated at y_(n+1) — the very thing we are trying to find. The unknown appears on *both* sides. That makes Adams-Moulton an implicit method: each step is an equation to be solved for y_(n+1), not a recipe to plug into. For a typical nonlinear f this is genuinely harder than the explicit case, usually requiring an iteration to crack. So why bother? Because at the same number of steps an Adams-Moulton formula is consistently more accurate than its Adams-Bashforth sibling, and — as the next guide will make precise — implicit methods have far better stability, which is exactly what you need when an equation is stiff. The implicitness is a feature you pay for, not a bug.
Predictor-Corrector: Guess, Then Refine
Here is the elegant resolution. The explicit Adams-Bashforth method is cheap but slightly cruder; the implicit Adams-Moulton method is more accurate but needs a value of y_(n+1) it does not yet have. What if we let the cheap one *supply the starting guess* for the accurate one? That pairing is the [[predictor-corrector-method|predictor-corrector method]], and it is one of the prettiest ideas in numerical analysis. First predict with an explicit Adams-Bashforth step to get a provisional answer, call it y*_(n+1). Then correct: use y*_(n+1) only to evaluate the slope f(x_(n+1), y*_(n+1)), feed that into the implicit Adams-Moulton formula, and out drops a refined, more accurate y_(n+1).
The deep trick is what this does to the implicit method's difficulty. Adams-Moulton was hard because the unknown sat on both sides of an equation. But once the predictor hands us a good guess for y_(n+1), we use that guess *only* on the right-hand side to compute one slope — so the corrector becomes a plain, explicit plug-in. We have sidestepped solving the implicit equation by replacing it with exactly one iteration starting from a smart initial guess. In effect, the predictor turns an equation-to-be-solved into a formula-to-be-evaluated, and the corrector cashes in most of the implicit method's superior accuracy for the cost of just one more f evaluation.
- Bootstrap: take the first few steps with a single-step method like RK4 to fill the history window, since a multistep method cannot start from one point alone.
- Predict (P): apply the explicit Adams-Bashforth formula to the stored slopes to get a provisional y*_(n+1). This needs no new f evaluation beyond what you have.
- Evaluate (E): compute the slope at the predicted point, f*_(n+1) = f(x_(n+1), y*_(n+1)). This is the one genuinely new evaluation of f.
- Correct (C): substitute that slope into the implicit Adams-Moulton formula to get the refined y_(n+1) — now an explicit plug-in, not an equation to solve.
- Optionally evaluate again (the final E) to store the corrected slope for the next step's history, then advance the window and repeat. This common pattern is called PECE.
A Free Error Estimate, and an Honest Verdict
There is a wonderful bonus hiding in the predictor-corrector pairing, and it is the reason these schemes earned their place in real software. The predictor and the corrector are different formulas of the same order, so they make slightly different errors on the same step. The *gap* between the predicted y*_(n+1) and the corrected y_(n+1) is therefore a direct, computable estimate of the local truncation error — the method essentially tells you how wrong it just was, for free, by comparing its own two guesses. That estimate is exactly the signal an adaptive driver needs: if the gap is large, the step was too ambitious and h should shrink; if it is tiny, you are wasting effort and h can grow. The next guide builds adaptive stepping on precisely this kind of cheap, built-in error sensor.
So which should you reach for — a single-step Runge-Kutta method or a multistep predictor-corrector? Be honest about the trade-off rather than picking a favorite. When evaluating f is *expensive* (say each call solves a big subproblem), the multistep approach shines, because it sips one or two evaluations per step where RK4 gulps four. When f is *cheap* but you need to change the step size often, or you are just starting out, single-step methods win for their effortless self-starting and trivial step changes. There is no universal champion here — only a balance between cost-per-step and flexibility, and good production solvers like the classic Adams codes are built to lean on the cheap side while managing the housekeeping for you.