From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,31d67020d4b04d5b X-Google-Attributes: gid103376,public From: Jonathan Guthrie Subject: Re: Simple Real_Time.Time_Span question Date: 1998/10/14 Message-ID: <702oll$1v4$1@news.hal-pc.org>#1/1 X-Deja-AN: 401058121 References: <6vvsgo$rvo$1@nnrp1.dejanews.com> <7003e4$534@hacgate2.hac.com> <700ic6$q1p$1@nnrp1.dejanews.com> Organization: Houston Area League of PC Users User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (Linux/2.0.34 (i486)) Newsgroups: comp.lang.ada Date: 1998-10-14T00:00:00+00:00 List-Id: Robert I. Eachus wrote: > In article <700ic6$q1p$1@nnrp1.dejanews.com> dennison@telepath.com writes: > > Thus a package billed as "Real_Time" ought to provide a portable way to get > > a floating point value of a delta time (time_span). Where is it? > 1) You've got to be kidding! Converting time to floating point to > do calculations is what caused problems with the Patriot system in > Dahran. This is not correct or, more correctly, is misleading. (I'm basing this reply on the write-up that was in DDJ a year or so after the fact.) The problem most certainly was NOT the fault of doing time calculations in floating-point. The problem was determining the time by adding the (admittedly floating-point) duration of the timer tick to a "time elapsed since system start" value. Since the duration of each timer tick is subject to round-off error, and since that round-off error is constant, adding all that stuff up causes that round-off error to accumulate. Eventually, that accumulated error becomes significant. That is what happened during the famous Patriot missile failure. Of course, the correct approach is either to count integral numbers of ticks and then find the current time when you want to know it by multiplying the tick count by the duration of each tick or to make sure that the units of the time intervals are themselves integral. If, for example, you have a 100Hz timer tick, measuring intervals in seconds and fractions therein is not a good idea, but counting them in milliseconds works just fine whether you're accumulating floating-point values or integer. Note that while using floating-point values to accumulate the time make it easy to screw up this way, they are neither necessary nor sufficient for the problem to occur. You can accumulate integral values in a floating-point number, or have round-off error with integers. In the case in question, as long as you don't determine the overall time span by adding up a series of smaller time_spans, you should be okay. (You might even be okay if you add up the series, but I don't know Ada well enough to guarantee it.) -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area.