|
From: | Clément K . Michel |
Subject: | [certi-dev] CERTI, floating-point and integer time representation |
Date: | Thu, 12 Oct 2017 15:58:28 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
Hi,
We
are currently envisioning to integrally use integer time in
CERTI.
As [1] and [2] showed, using a floating arithmetic value to store time proves itself to be challenging. [3] affirms on page 233 that programmers who use floating point arithmeric almost never want to test if two computed values are exactly equal to each other (or at least they hardly ever should try to do so). As with CERTI, the current implementation, described in libCERTI/FedTimeD.hh, compares two doubles up to a precision epsilon, the epsilon being itself a double.
The choice of epsilon is quite a complex one, as it depends of the magnitude of the numbers to be compared. A small epsilon means number with a high magnitude that should be equal will not be. Conversely, using a big epsilon means number with a low magnitude that should not be equal will be considered as if they are. All of this considered, we find it either extremely difficult to justify that the current double implementation is well-made and free of errors. These errors can happen for two reasons : 1. Comparing two floating point numbers 2. Converting a floating point number to another representation and vice-versa
Case 1 happens when we deal with multiple elements, as we need to
get the earliest. In a context of distributed simulation, we are
sure this situation is bound to happen in almost every case. Case 2 happens when we send data to a federate using another time representation. This is done multiple times through the libRTI branches ieee1516-2000 and ieee1516-2010, plus the potential difference in implementation between the libRTI and the federate time implementation.
As outlined by these recent publications all pointing out the issues of the floating-point representation for timekeeping, I believe that the RTIG should use the HLAinteger64Time time type defined in IEEE 1516-2010, as they are "considerably easier to understand and debug. If a floating-point value is required in the calculation, this can be achieved in the interpretation of the value. You may for example consider using an integer that is interpreted as microseconds." [2] [1] states that their solution "requires an explicit choice of
time resolution that quantizes time so that arithmetic on time
values is performed on integers only, something that modern
computers can do exactly, without quantization errors. Moreover,
we have shown that such an integer model of time can be used in a
practical co-simulation environment, and that this environment can
even embrace components that internally use floating-point
representations of Newtonian time, for example to model continuous
dynamics without discrete behaviors". As such, we are envisioning the integral use of an integer-based
form of time in CERTI. It would still be possible to use doubles
with CERTI, however this conversion should occur in the federate
rather than in the RTI, as outlined by [1]. The envisioned change
seems more compatible with the papers quoted. We would like to know if anyone familiar with the intricate architecture of CERTI would know exactly where the consequences of this change would go. Moreover, we want this change not to break compatibility with the existing version, and would like to offer this integer time as either a different branch, or as a compilation option. As of now, we do not know exactly how to implement this in a way compatible with the existing architecture.
The envisioned modification would impact:
As of the code, this would mean:
Right now, a header HLAInteger64Time is present within the source
code of CERTI, but doesn't seem to be called anywhere. It might be
interesting to write the associated .cc and replace all CERTI time
representations by HLAInteger64Time (as hinted by [2]), but we do
not know yet the best way to make this change as low-cost as
possible.
These envisioned changes are quite important, and would break the
compatibility of future CERTI versions if implemented in
place. Thus, we find it better to make the use of the
integer time an option, for instance available at compilation
time.
[1] Cremona, F., Lohstroh, M.,
Broman, D., Tripakis, S., Lee, E.A., 2017. Hybrid Co-simulation:
It’s About Time (No. UCB/EECS-2017-6). University of California
at Berkeley.
[3] Knuth, D.E., 1997. The art of computer programming, 3rd ed. ed. Addison-Wesley, Reading, Mass. |
[Prev in Thread] | Current Thread | [Next in Thread] |