Bisection method

The formula

The setup is an equation written as f(x) = 0, and a starting bracket [a, b] where the function changes sign:

f(a) · f(b) < 0

That one line says a and b sit on opposite sides of a root. Each step computes the midpoint and checks which half keeps the sign change ^[4]:

c = (a + b) / 2
if f(a) · f(c) < 0   ->   root is in [a, c],  set b = c
else                 ->   root is in [c, b],  set a = c

That reads: split the bracket, keep the half that still straddles zero, throw the other half away.

The bracket width halves every pass, so after n midpoints the error is bounded ^[4]:

|c_n − r| ≤ (b − a) / 2ⁿ

r is the true root, c_n is the n-th midpoint. Read it as: your worst-case error is the original bracket width divided by two, n times over — guaranteed, no assumptions about the function's shape.

Turn that around to size the job before you start. To hit a tolerance ε:

n ≥ log₂( (b − a) / ε )

That says: pick your accuracy, take the log base 2 of how many times you have to halve the starting bracket to get there, and that's how many function evaluations it costs. No surprises.

Where you meet it

Solving an implicit design equation on the bench. The Colebrook equation for pipe friction factor, the beam-column interaction check, orifice sizing — plenty of engineering relations can't be algebraically solved for the variable you want. You know the answer is between two values because physics bounds it (a friction factor lives between 0 and 1; a valve position between 0 and full travel). Bracket it, bisect it, done. It will not diverge on you the way Newton's method can.
Firmware with no floating-point unit. On an 8-bit motor controller or a sensor node, bisection needs only add, divide-by-two (a bit shift), a sign test, and a call to your model. No derivatives, no matrix, no library. Root finding you can hand-audit and put in front of a safety review board.
Back-solving a calibration curve on a test stand. You have a monotonic transducer curve — thermocouple voltage to temperature, load cell counts to force — and you need the input that produces a measured output. Bisection on curve(x) − measured = 0 inverts any monotonic curve without fitting an inverse polynomial.
The bulletproof fallback inside a smarter solver. Production root finders in the Brent–Dekker family (MATLAB's fzero, SciPy's brentq) run fast secant or inverse-quadratic steps but fall back to a bisection step whenever the fast step tries to jump outside the bracket. Bisection is the guardrail that guarantees the whole thing converges.

How it works

The engine underneath is Bolzano's intermediate value theorem: a continuous function that is negative at one end of an interval and positive at the other has to cross zero somewhere between them. Bisection doesn't approximate that crossing with a model of the curve — it just interrogates the sign, which is the one thing the theorem promises. That's why it never diverges. Every other root finder trades robustness for speed; bisection is the one that gives up speed for a guarantee.

The convergence is linear — one binary digit of accuracy per iteration, roughly one decimal digit every 3.3 iterations. Concretely: f(x) = x² − 2 on the bracket [1, 2] converges to √2. To reach ε = 1e-6, the formula predicts log₂(1 / 1e-6) ≈ 19.9, so 20 midpoints; run it and the 20th midpoint lands within about 6e-7 of 1.41421356, exactly as the (b − a)/2ⁿ bound allows. Predictable to the iteration. That's also the knock against it: Newton's method would nail the same root to machine precision in four or five steps. If you're calling your model millions of times, that gap matters.

Where people get burned:

No sign change, no bracket. If f(a) and f(b) have the same sign, the method has nothing to work with — either there's no root in there, or there's an even number of them. The algorithm can't tell those apart. Feeding it a bad bracket is the number-one mistake, and a lot of implementations silently return garbage instead of erroring out.
Even-multiplicity roots are invisible. A function that touches zero and bounces back — f(x) = (x − 3)² — never changes sign, so bisection walks right past the root. It finds crossings, not touches. Tangent contacts, double roots, and grazing minima all slip through.
It brackets one root, not the right root. If your interval contains three crossings, bisection converges to one of them, and which one depends on the arithmetic, not on which one you wanted. Bracket tightly around the root you actually care about.
Continuity is the fine print. A sign change across a discontinuity — a 1/x-style pole, a piecewise jump — looks exactly like a root to the sign test. Bisection will happily converge on the discontinuity. It assumes the function is continuous on the bracket; if it isn't, the guarantee evaporates.
Floating-point floor. Once the bracket shrinks to a couple of adjacent representable numbers, the midpoint stops moving and further iterations buy nothing. Stop on |f(c)| < tol, on bracket width, or on a hard iteration cap — never loop "until c stops changing," which can spin forever near the precision floor.

History

The idea is old, and it started as a way to prove things exist, not to compute them. In 1594 the Flemish engineer Simon Stevin — a military quartermaster and bookkeeper by trade, the man who popularized decimal fractions — described a procedure for extracting the root of a polynomial by chopping an interval into ten equal pieces, finding the piece where the sign flips, and repeating to grind out one decimal digit at a time ^[1]^[2]. That's interval-halving's older cousin, interval-tenthing, and it's the same divide-and-keep-the-sign-change logic.

The rigor came two centuries later. In 1817 the Bohemian priest and mathematician Bernard Bolzano published Rein analytischer Beweis — "Pure Analytical Proof" — giving the first rigorous, arithmetic (not geometric) proof of the intermediate value theorem, the exact guarantee bisection leans on ^[1]^[3]. Bolzano's proof used a nested-interval argument that is bisection in disguise: halve, keep the half that brackets the crossing, repeat, and show the shrinking intervals close on a single point. In the same 1817 paper he defined what we now call a Cauchy sequence — four years before Cauchy's own 1821 Cours d'Analyse, which gave the theorem its modern statement and a proof echoing Stevin's decimal construction ^[1]^[2]. Bolzano's work was largely ignored in his lifetime; the theorem carries his name today mostly because later mathematicians rediscovered how far ahead of them he'd been. The numerical method that falls straight out of his proof is why every engineer who has ever bracketed a root owes a quiet debt to a priest whose papers nobody read.

Related tools

/tools/pipe-pressure-drop — friction-factor and head-loss relations that hide implicit equations bisection can solve
/tools/euler-buckling — the kind of monotonic design check you back-solve for a critical value
/tools/normal-shock — compressible-flow relations often inverted numerically for Mach number
/tools/isentropic-flow — area-Mach and pressure-ratio relations that are implicit in Mach and solved by bracketing
/tools/reynolds-number — feeds the flow regime that sets up the implicit friction-factor solve

Sources

Written by HE in our own words from the cited sources — engineering judgment included, your stamp still required. All entries →