Symplectic vs Explicit Euler

The previous lesson mentioned two Euler variants that differ by the order of two lines. That single reordering matters enormously once you run thousands of steps.

Explicit (forward) Euler updates position using the OLD velocity, then updates velocity:

Symplectic (semi-implicit) Euler flips the order: update velocity first, then use the NEW velocity for position:

Both are first-order methods with the same per-step cost and the same asymptotic error (O(dt^2) per step). So why bother swapping two lines?

Energy behavior

Run explicit Euler for a long simulation — an orbit, a pendulum, a mass on a spring — and total energy drifts upward. Orbits spiral outward, pendulums swing higher each period, springs oscillate with growing amplitude. This is not floating-point rounding; it is structural. Explicit Euler does not preserve phase-space volume, so its error accumulates in one direction forever.

Symplectic Euler costs exactly the same per step but nearly conserves energy — it oscillates in a bounded band around the true value instead of drifting away from it. It is still not exact (that is what RK4 or implicit integrators are for), but for real-time simulation, bounded error beats unbounded drift. This is why real-time physics engines (Box2D, Bullet, Chipmunk) universally use symplectic Euler and never plain explicit Euler, even though both are equally cheap to compute.

Same inputs, different trajectory

For a constant force (gravity with no drag or spring term, as in this exercise's tests), the velocity sequence is identical either way — the velocity update never reads position, so the order between the two lines cannot change it. Position is the only quantity that differs: explicit Euler always advances position using the velocity from before the current step's update, so its position lags symplectic's by exactly one step's worth of the velocity change. That is the entire gap you will see in this exercise's output — same final velocity, different final position.

Once a force depends on velocity (drag: F = -c*v) or position (a spring: F = -k*x), both velocity AND position can diverge between the two methods, not just position — the feedback loop compounds the ordering difference every step.

Implementation checklist

• Accumulate force from every source (gravity, springs, drag, input) before integrating; reset it to zero after each step.
• Convert to acceleration once per step: a = F / m.
• Pick ONE order and apply it to every body in the simulation — mixing orders across bodies makes constraint solving inconsistent.
• Default to symplectic Euler unless you have a specific reason not to (e.g. reproducing a reference implementation, or swapping in RK4 for an offline, higher-accuracy solver).

The exercise runs both integrators side by side on identical input so you can see the divergence directly instead of taking it on faith.