comp.lang.ada
 help / color / mirror / Atom feed
From: Jonathan Guthrie <jguthrie@weck.brokersys.com>
Subject: Re: Simple Real_Time.Time_Span question
Date: 1998/10/14
Date: 1998-10-14T00:00:00+00:00	[thread overview]
Message-ID: <702oll$1v4$1@news.hal-pc.org> (raw)
In-Reply-To: EACHUS.98Oct14130031@spectre.mitre.org

Robert I. Eachus <eachus@spectre.mitre.org> 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.





  reply	other threads:[~1998-10-14  0:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-10-13  0:00 Simple Real_Time.Time_Span question dennison
1998-10-13  0:00 ` David C. Hoos, Sr.
1998-10-13  0:00   ` dennison
1998-10-14  0:00     ` Robert I. Eachus
1998-10-14  0:00       ` Jonathan Guthrie [this message]
1998-10-15  0:00         ` dennison
1998-10-16  0:00           ` Tucker Taft
1998-10-16  0:00             ` dennison
1998-10-16  0:00               ` dewar
1998-10-17  0:00           ` Niklas Holsti
1998-10-14  0:00       ` Keith Thompson
1998-10-14  0:00     ` Niklas Holsti
1998-10-14  0:00       ` Niklas Holsti
1998-10-13  0:00 ` dennison
1998-10-13  0:00 ` Tucker Taft
1998-10-14  0:00 ` dewar
1998-10-14  0:00   ` dennison
1998-10-14  0:00     ` Matthew Heaney
1998-10-14  0:00     ` Robert I. Eachus
1998-10-15  0:00       ` dennison
1998-10-16  0:00         ` Robert I. Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox