The computer science behind TBM interception is a fascinating problem with very high stakes consequences, as occurred on February 25, 1991.<p>I was an active duty Patriot Technician and Systems Mechanic (24T) during that time; and even though we were rebooting our systems regularly to diminish the impact of this roundoff error, there were other critical timing issues during the intercept stage.<p>TBM interception involves the science and math behind a "bullet hitting a bullet". These are extremely high velocities converging on each other.<p>To Raytheon's credit, they were iterating rapidly and released patches almost daily as new data was collected.<p>Even when we managed to launch a Patriot to engage an oncoming Scud, success was dependent on the proximity fuzed warhead detonating at just the perfect predictive moment ahead of the projectile. This timing was perfected over a decade in White Sands NM using lower velocity drones. But Patriot's software was not optimized for TBM-scale velocity (it is now).<p>A "perfect" hit typically resulted in a shower of hot metal and undetonated debris raining down on civilian populations.<p>From a game theory perspective, this is basically a no-win situation. You're just trying to minimize collateral damage once a theater of operations escalates to using TBMs.
I’ll never forget my Computational Methods professor discussing exactly this project, and how a lack of knowledge or care about things like the conditioning of your routines, or compounding rounding errors in floating point, could literally get people killed.<p>Most of the students laughed at this idea.
Also: "As a stopgap measure, the Israelis had recommended rebooting the system's computers regularly."<p><a href="https://en.wikipedia.org/wiki/MIM-104_Patriot#Failure_at_Dhahran" rel="nofollow">https://en.wikipedia.org/wiki/MIM-104_Patriot#Failure_at_Dha...</a>