The formula
Forward (explicit) Euler, the one you meet first:
y_{n+1} = y_n + h · f(t_n, y_n)
Reading: the next value equals the current value plus the step size h times the slope evaluated right now. The slope f(t, y) is whatever your differential equation y' = f(t, y) says the rate of change is. You're pretending the slope holds constant across the whole step.
Backward (implicit) Euler, the same idea aimed at the far end of the step:
y_{n+1} = y_n + h · f(t_{n+1}, y_{n+1})
Reading: use the slope at the end of the step instead of the start. The catch is that y_{n+1} shows up on both sides, so you have to solve for it — algebraically if the equation is linear, with a Newton iteration if it isn't.
The step size and the errors:
local error per step ~ (h²/2) · y'' (order h²)
global error at fixed time ~ h (order h¹)
Reading: halve the step and each individual step gets four times more accurate, but you take twice as many of them, so the accumulated error only halves. That trade — second-order local, first-order global — is why Euler is called a first-order method.
Where you meet it
- Any real-time control loop on the test stand. A PID controller sampling a load cell at 1 kHz and integrating error is running forward Euler whether the firmware says so or not.
integral += error · dtis the Euler update. When the loop goes unstable at a high gain, part of what you're fighting is the step size interacting with the dynamics. - The first cut of a plant model at a design review. Somebody wants to know how a thermal mass, an actuator, or a battery cell responds over time before anyone builds hardware. The quickest thing to code — in MATLAB, a spreadsheet, or C on the target — is an Euler march. It's fine for a sanity check and dangerous if it ships unexamined.
- Explicit solvers inside the big tools. Explicit transient FEA (LS-DYNA's explicit solver, crash and impact codes) and explicit CFD schemes are forward Euler's descendants, and when one of those sims "blows up" — displacements ringing to ±1e30, temperatures going negative — you're usually watching the Euler stability limit get violated. SPICE tells the same story from the other side: circuit simulators use implicit integration only (backward Euler, trapezoidal, Gear) precisely because circuits are stiff and explicit Euler couldn't survive a timestep sized for the slow behavior you actually care about.
- Sensor fusion and dead reckoning. An IMU integrating acceleration to velocity to position between GPS fixes is stacking Euler steps. The drift you see is dominated by sensor bias and noise rather than truncation error, but it accumulates through that stack exactly the way global error does — one step at a time, unbounded until the next fix.
How it works
The mental model is honest: you stand at a point, read the slope the equation hands you, and walk in a straight line for one step. Then you re-read the slope and turn. The true solution is a smooth curve; you're approximating it with a chain of little chords. Where the curve bends away from your chord, you fall behind — that's the truncation error, and because exponentials are convex the chord always lands below the curve: Euler lags a growing exponential (undershooting the upward bend) and overshoots the decay of a dying one, sitting under the true curve — and past h = 2/|k| it overshoots straight through zero.
The mistake people make is trusting a small step to buy accuracy without watching stability. Those are two different failures. Accuracy is about the size of the error. Stability is about whether the error grows on its own, independent of the true solution, until the numbers are garbage.
Here's the stability limit, and it's worth burning into memory. Take the test equation y' = k·y. One Euler step multiplies the current value by the amplification factor (1 + h·k). For a decaying system — k real and negative — the true answer shrinks every step, so you need |1 + h·k| < 1, which works out to:
h < 2 / |k|
Cross that line and the simulation doesn't just get inaccurate — it explodes, oscillating with a growing amplitude while the real system is quietly settling. Concrete case: y' = -2.3·y, true answer decays like e^(-2.3t). Step at h = 1 and the amplification factor is 1 + (1)(-2.3) = -1.3. The Euler march goes 1, -1.3, 1.69, -2.20, 2.86, ... — flipping sign and growing without bound while the actual solution is heading to zero. Drop to h = 0.5 (factor -0.15, now inside the unit limit) and it collapses toward zero as it should. The fix wasn't more precision; it was getting under 2/|k|.
The k that matters is the fastest eigenvalue of your system — the stiffest mode, the shortest time constant. A model with one slow mode you care about and one fast mode you don't will still force you to take tiny steps sized for the fast mode, or blow up. That situation is called stiffness, and it's where explicit Euler stops being cheap: you either take absurdly small steps or you switch methods.
That's what backward Euler buys you. Solving at the far end of the step gives an amplification factor of 1 / (1 - h·k), which stays below 1 for every positive h when k is negative. It's unconditionally stable — A-stable, in the textbook term. Same stiff problem y' = -2.3·y at h = 1 marches 1, 0.30, 0.09, 0.028, ..., decaying cleanly, no oscillation, no step-size handcuffs. The price is solving an equation each step, and backward Euler is still only first-order accurate, so it can be stable and sloppy at the same time — smooth-looking garbage. Stability keeps the sim from exploding; it does not make the answer right.
Two more things practitioners get wrong. First, they compare an Euler result to itself at two step sizes, see them agree, and call it converged — but two wrong-and-stable answers can agree with each other. Check against a known solution or a higher-order method. Second, they forget that when you halve h you double the number of steps, so per-step rounding error accumulates faster; past a point, shrinking h on limited precision makes things worse, not better. For real work, reach for RK4 (fourth-order, far more accuracy per step) or a stiff solver. Keep Euler for what it's good at: the intuition, the quick check, and the tight embedded loop where you control h and know your fastest mode cold.
History
Leonhard Euler was born in Basel, Switzerland, in 1707, and spent his career bouncing between the two great academies of the age — St Petersburg from 1727, Berlin from 1741, then back to St Petersburg in 1766, where he worked until his death in 1783, producing nearly half his output after going effectively blind [1][2]. He was, by most counts, the most prolific mathematician who ever lived, and this method is a footnote in his catalog rather than a headline.
He laid it out in Institutiones calculi integralis ("Foundations of Integral Calculus"), the three-volume treatise on integral calculus he published from 1768 to 1770 [1][3]. The problem he was chewing on was ancient and practical: you have a differential equation you can't solve in closed form — most of them, it turns out — and you still need numbers out of it. His move was to chop the interval into small pieces and assume the rate of change held roughly constant across each one, walking the solution forward as a polygon of straight segments approximating the true curve [3]. Simple enough that it reads like something a first-year student would guess, which is exactly why it endured.
For nearly two centuries it was mostly a pen-and-paper technique, useful but limited by how much arithmetic a human could stomach. The interesting turn came with computing. During the American space program, Euler-style step-by-step integration of trajectory equations was among the hand calculations engineers used before machine computation was trusted — the kind of ground-truth arithmetic that verified the electronic computers rather than the other way around. The method that Euler wrote down to grind through intractable equations by hand became, once machines could do the grinding, the seed of every numerical integrator in every simulation package on the planet.
Related tools
- /tools/euler-buckling
- /tools/vibration-natural-freq
- /tools/rc-charge-time
- /tools/pendulum-period
- /tools/reynolds-number