RE: [boost] Patriot Calculation Failure (was Date/Time formal review)

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-05-02 19:13:38

Gary Powell wrote:
> So would the use of the boost Date/Time library have caught this
> time/clock bug?
>
> >
> > http://www.ima.umn.edu/~arnold/disasters/patriot.html

Difficult to say.  Based on the information in the article, it makes me think the the inacurracy was
created in what amounts to the 'clock subsystem'.  That is the low level drivers that measure time.
Given a conversion error at this lowest level it is unclear to me if the problem would be resolved by
use of a time library. It seems to me that the fundamental flaw is that the accuracy of the position
projection is dependent on the uptime of the system.  Not good.

Having said that, however, there is one statement in the page gives me pause:
"Ironically, the fact that the bad time calculation had been improved in some parts of the code, but
not all, contributed to the problem, since it meant that the inaccuracies did not cancel."

I'm not exactly sure what that means, but it sounds like a violation of the 'write once and only once'
principle.  Thus, it is possible that a single time library with well understood range limits, or
built on an unlimited precision type, might have helped.

Perhaps the most amazing thing here, is that apparently this somehow wasn't tested.  Although, as I
recall the Patriots were initially built to shoot down planes, which fly slower than SCUDS, and they
had to be 'rapidly adapted' for the SCUD mission.  So even though this article doesn't mention this,
it makes you wonder if there weren't other factors involved as well.

BTW, this particular problem might be more in the domain of SIUnits which would provide types for both
the time and the velocity.  Even so, I don't know that SIUnits would help any more than a time library
if you only have 24 bits...

Jeff