Why one fixed step is the wrong question
By now you can integrate an initial-value problem beautifully: pick a step h, march from x_n to x_{n+1} with RK4, and the global error falls like O(h^4). But every step in those earlier guides used the same h for the whole journey — and that is almost never what you want. Picture a comet swinging past the sun: for months it drifts in nearly a straight line, then in a few hours it whips around perihelion. A step small enough to resolve that whip would, if used everywhere, waste millions of pointless steps out in the calm.
So the right question is not 'what step size?' but 'what error per step can I tolerate, and what step delivers exactly that, right here?' This is adaptive step-size control: a good integrator keeps a running estimate of the local truncation error each step would commit, and stretches or shrinks h on the fly so that error stays near a user-set tolerance. Big steps in the calm stretches, tiny steps through the violent ones, and roughly equal error spread along the whole path — that is the goal.
Estimating the error you cannot see
Here is the catch: to control the error you must first estimate it, yet you never know the true solution to compare against. The trick is to take the same step twice with methods of different order and read the error off the gap between them. The cleanest version is an embedded Runge-Kutta pair, such as the famous Runge-Kutta-Fehlberg or the Dormand-Prince pair behind MATLAB's ode45. A single set of stage evaluations is combined with one set of weights to give, say, a 5th-order estimate, and with a second set of weights to give a 4th-order estimate — two answers from one batch of work.
The difference between the two answers is dominated by the lower-order method's error, so it is a cheap, honest estimate of how wrong this step is — call it err. The beauty of embedding is that the two formulas share their stage evaluations: you get the error estimate almost for free, not by redoing the step with a whole separate method. (Recall that the per-stage slope evaluations of f are the dominant cost of any Runge-Kutta method; reusing them is what makes adaptivity affordable.)
Once you have err and a tolerance tol, basic calculus tells you how to pick the next step. If the method's error scales like h^(p+1), then to bring err down to tol you scale h by the ratio (tol/err) raised to the power 1/(p+1). A common, slightly conservative recipe is shown below. If err already sits under tol, you keep the step and grow h for next time; if err overshoots, you reject the step, shrink h, and redo it — never carrying a too-large error forward.
One adaptive step (embedded pair of orders p and p+1):
take step h -> y_high (order p+1), y_low (order p)
err = || y_high - y_low || # cheap error estimate
ratio = ( tol / err ) ^ ( 1 / (p+1) )
h_new = SAFETY * h * ratio # SAFETY ~ 0.9
if err <= tol: accept y_high, advance, use h_new next
else: reject step, set h = h_new, redoMultistep methods: remember, don't recompute
Runge-Kutta methods are one-step: to advance from x_n they look only at y_n, and they buy high order by evaluating the slope f at several scratch points inside the step — points that are then thrown away. A linear multistep method takes the opposite bargain. It is one-step amnesia turned into long-term memory: to compute y_{n+1} it reuses the slopes f(y_n), f(y_{n-1}), f(y_{n-2}), ... that it already computed and stored on previous steps. Old work is not discarded; it is recycled.
The classic family is the Adams methods. Picture the past few stored slopes; fit a polynomial through them, then integrate that polynomial over the next interval to predict how y moves forward — this is exactly the 'replace then integrate' move from the quadrature rung, applied to the slope. Adams-Bashforth does it with only past, already-known slopes, so it is explicit: one formula, no solving, and crucially one new f-evaluation per step however high the order. That is the headline win — RK4 costs four slope evaluations per step; a fourth-order Adams-Bashforth costs essentially one.
There is no free lunch, of course. A multistep method needs several past points before it can start, so it cannot bootstrap itself from a single initial condition — you must prime the pump with a one-step method (often RK4) for the first few steps. It also dislikes changing h: the stored slopes are spaced at the old step, so a clean step-size change means re-deriving the coefficients or re-interpolating the history, which is why adaptive multistep codes are fiddlier than adaptive RK. The trade is fewer function calls per step against a bumpier, history-bound machine.
Predictor-corrector: guess, then refine
If instead you fit the polynomial through the past slopes *and the new one at x_{n+1}*, you get an Adams-Moulton method — but now the unknown y_{n+1} appears on both sides of the equation, since f(y_{n+1}) needs the very value you are solving for. The method is implicit: you cannot just plug and chug, you must solve an equation for y_{n+1} each step. Implicit methods are more accurate and far more stable for a given order, which is precisely why they matter for the stiff problems of the next guide — but solving that equation costs something.
The elegant compromise is a predictor-corrector method. First the cheap explicit Adams-Bashforth predicts a provisional y_{n+1}. Then you plug that guess into the right-hand side of the implicit Adams-Moulton formula to correct it — turning the hard implicit equation into one easy explicit evaluation. You may apply the corrector once, or iterate it a couple of times to taste. As a bonus, the gap between the predictor's and the corrector's answers is itself a free local-error estimate, ready to drive adaptive step control just like the embedded RK pair did.
BDF, and the wall that explicit methods hit
Adams methods fit a polynomial to past slopes and integrate it. There is a second, equally important multistep family that fits a polynomial to past solution values y_n, y_{n-1}, ... and forces its derivative at x_{n+1} to match f: these are the backward differentiation formulas, or BDF. They are implicit by construction, and they are the method of choice for one notorious class of problems — stiff ones, where some components of the solution decay ferociously fast while others crawl.
Here adaptivity alone is not enough, and this is the honest punchline of the whole rung. On a stiff equation an explicit method — RK4, Adams-Bashforth, no matter how clever your step controller — is forced to take absurdly tiny steps not for accuracy but for sheer numerical stability: take one step too large and the computed solution explodes into oscillations that have nothing to do with the true, smoothly-decaying answer. The adaptive controller dutifully slams h down to keep things from blowing up, and your run grinds to a crawl while the true solution sits there doing almost nothing.
Implicit methods — BDF above all — escape this trap because their region of stability is vast, so they can take large steps sized by accuracy even on a stiff problem. That is why production ODE solvers ship two engines: an explicit adaptive RK (like ode45) for ordinary problems, and an implicit BDF code (like ode15s) for stiff ones. Why implicit wins, what 'region of absolute stability' actually means, and how to spot stiffness before it wrecks your run — that is exactly the story of the next and final guide in this rung.