Robotics Systems Types

We discussed this and it seems better to keep the current definition. Sorry.

There were four major arguments:

SI Units¶

In favor of change: We try to use SI units without magnitude prefixes, wherever possible.

Precision¶

Inconclusive: Experiments show that, in general, uint64 and double-float, but not single-float, provide enough precision for accurate timestamp calculation:

CL-USER> (let* ((now    (local-time:now))
                (a/sec  (local-time:timestamp-to-unix now))
                (a/nsec (local-time:nsec-of now))

                (ai     (+ (* 1000000 a/sec) (floor a/nsec 1000)))
                (af     (float ai 1.0f0)) ; single float
                (ad     (float ai 1.0d0)) ; double float

                (bi     (+ (* 1000000 0) (+ (floor a/nsec 1000) 1)))
                (bf     (float bi 1.0f0)) ; single float
                (bd     (float bi 1.0d0)) ; double float
                )
           (format t "Integer   ~20D   - ~20D   = ~20D~%Single Float~20F -   ~20F =   ~20F~%Double Float~20F -   ~20F =   ~20F~%" 
                   bi ai (- ai bi) 
                   bf af (- af bf)
                   bd ad (- ad bd)))
Integer                 166762   -     1354300814166761   =     1354300813999999
Single Float            166762.0 -     1354300800000000.0 =     1354300800000000.0
Double Float            166762.0 -     1354300814166761.0 =     1354300813999999.0

Efficiency¶

Against change: In most cases, manipulation of integers is more efficient than manipulation of floats.

Common Practice¶

Against change: It was our impression that in most related work, timestamps are represented as integer/msec or integer/µsec.

Conclusion¶

We came to the conclusion that it would be best to keep the uint64/µsec representation and convert to float/sec in clients who want this (maybe with support from Rosetta Stone Project).

If nobody objects, I would add this explanation/rationale to the documentation strings of the data type and reject the issue.