[certi-dev] CERTI, floating-point and integer time representation

[Clément K . Michel]

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:

• The RTIG, as it would process integer times instead of FedTime's double
• The RTIA, as it would receive and send integer times instead of FederateTime's double (recall that FederateTime is a typedef of FedTime), even if it can use in
  
• The RTIAmbassadorImplementation, as it would receive and send integer times instead of FederateTime's double

As of the code, this would mean:

• Changing the libCERTI/M_Classes to send and receive integer instead of doubles
• Changing the FedTime (and in the same way, the typedef'd FederationTime), removing the (useless in an integer time) epsilon
  
• Changing the variables initialization
• Changing the PrettyDebug display of the time

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.
How to well implement this option is not yet know: it may be simpler to define conditional compilation, or to swap files around to allow compilation with multiple class definitions.

        [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.

        [2] Karlsson, M., Antelius, F., Möller, B., 2016. Time Representation and Interpretation in Simulation Interoperability - an Overview. Pitch.
        [3] Knuth, D.E., 1997. The art of computer programming, 3rd ed. ed. Addison-Wesley, Reading, Mass.