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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!telesoft!rlk From: rlk@telesoft.com (Bob Kitzberger @sation) Newsgroups: comp.lang.ada Subject: Re: Limits on type Duration and package Calendar Summary: not as easy as it seems Message-ID: <811@telesoft.com> Date: 6 Jul 90 02:13:41 GMT References: <57925@bbn.BBN.COM> Organization: TeleSoft, San Diego, CA. List-Id: In article <57925@bbn.BBN.COM>, mbrinn@bbn.com (Marshall Brinn) writes: > > In the LRM, it defines that type DURATION need only ranuge up to 84600.0, > ie., the number of seconds in a day (the definition of CALENDAR.DAY_DURATION). > > However, package CALENDAR provides functions "+" and "-" where the difference > between two times is given as a DURATION. How then does this package handle > the difference between two days that are more that one day apart? Some > compilers I've tried seem to have a reasonably high value for DURATION'last, > at least one (TELESOFT TELEGEN2 1.4) used the one-day upper bound. Since Duration is a fixed-point type, there is a trade-off between high resolution and a "reasonably high value" -- i.e. high upper bound. Using a _minimal_ number of bits to represent the integer portion of Duration (e.g. 17 bits and 1 sign bit) allows a _maximal_ number of bits to represent the fractional portion, a desirable approach for embedded systems in which accurate time measurements are important. For a 32-bit representation of Duration, this leaves 14 bits to represent the fractional portion, for a resolution of about 61 microseconds. It may be argued that non-embedded systems should have a larger number of bits for the integer portion of type Duration, though this begs the question of how many is enough to represent a "reasonably high value"? I know this doesn't answer your question... but maybe it sheds some light on the trade-offs compiler vendors have to make in implementing Ada's time abstraction. Things get much more complicated when you throw in System.Tick (which is relatively useless and hard to implement meaningfully), network time syhchronization, and low-level hardware timers whose values don't map exactly onto a binary fraction. IMHO, Calendar is trying to handle the time abstraction for two different problem domains that are better left separate -- 1) time-of-day calculations, and 2) real time measurements. Type Duration is the "bridge" between the two abstractions. Sigh. It looks to me like you'll need to "roll your own" solution, with calls to Calendar.Split to get the yr/mon/day/sec fields of both timne operands. Bob Kitzberger Software Engineer, Ada Tasking -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West San Diego, CA 92121-9891 "There's too much caffeine in your bloodstream..." (619) 457-2700 x163 -- The Smiths ------------------------------------------------------------------------------