Real-World Floating-Point Bugs

Throughout computing history, floating-point precision issues have caused spectacular failures. These real-world examples demonstrate why understanding IEEE 754 is not just academic but has practical life-and-death consequences.

1. Patriot Missile Failure (1991)

During the Gulf War, a Patriot missile defense system failed to intercept an incoming Scud missile, resulting in 28 deaths. The cause: the system tracked time by counting 0.1-second intervals in a 24-bit fixed-point register.

The value 0.1 in binary is 0.00011001100110011... (repeating). The 24-bit truncation introduced an error of about 0.000000095 seconds per tick. After 100 hours of continuous operation, this accumulated to 0.34 seconds — enough error that the tracking gate shifted by over 600 meters, causing the system to look in the wrong area of sky.

2. Vancouver Stock Exchange (1982)

The Vancouver Stock Exchange index was initialized at 1000.000 and recalculated after each trade by truncating (not rounding) to 3 decimal places. Each truncation lost a small amount of value. After 22 months of operation, the index read 524.811 instead of the correct value of approximately 1098.892. The exchange had to be recalibrated.

3. Ariane 5 Explosion (1996)

The Ariane 5 rocket exploded 37 seconds after launch. The cause: a 64-bit floating-point velocity value was converted to a 16-bit signed integer. The value exceeded 32,767 (the maximum for a 16-bit signed integer), causing an overflow exception. The backup system had the same bug. The resulting error data was interpreted as steering commands, causing the rocket to veer off course.

4. Excel 2007 Bug

Excel 2007 displayed certain calculated values of 65,535 as 100,000 due to a bug in the floating-point-to-string conversion. The values were stored correctly internally but rendered incorrectly. Specifically, 12 out of 2^52 values near 65,535 triggered the bug.

5. Sleipner A Platform (1991)

The Sleipner A concrete offshore platform sank during a ballast test, causing a loss of $700 million. The cause: a finite element analysis program used inadequate mesh resolution in modeling tricell walls. Approximation errors in the floating-point calculations led to a 47% underestimate of shear stress in a critical structural element.

Lessons learned:

1. Never accumulate small errors over long periods without compensating (Kahan summation)
2. Use appropriate precision for the domain — currency should use decimal or integer cents
3. Validate conversions between different numeric types and sizes
4. Test boundary conditions where floating-point values approach type limits
5. Use interval arithmetic in safety-critical applications to track error bounds