Time Precision
All about your logging frequency
In Marple, we round time input up to 1ns, which results in a supported precision of at most 1GHz.
In practice, we do not support precision up to 1ns in every case, this depends on what your time input looks like.
What you need to know
Marple expects timestamps to be uploaded in seconds. You should be aware that your timestamps might lose some precision due to rounding.
We consider two different ways of logging time, which will result in a different rounding precision:
Timestamps start from 0 (or another small offset) e.g. your timestamps look like 0.001, 0.002, 0.003,... In this case, timestamps are rounded at 1ns (1e-9s), resulting in a supported logging rate of 1GHz.
Timestamps are logged as epoch dates e.g. your timestamps look like 1693984725.15, 1693984725.20, 1693984725.25,... In this case, timestamps are rounded at 0.1µs (1e-7s), resulting in a supported logging rate of 10MHz.
In case your system logs timestamps as epoch dates, but you do require a precision up to 1ns, you can set an offset to subtract from your time input when importing your data. This way, you can let your timestamps start from 0 instead in Marple and get higher precision.
Why we use different rounding - the technical side
The difference in allowed precision is caused by Marple using floating points to represent timestamps when visualising your data.
Floating point numbers work by representing real numbers as a fraction (mantissa) and an exponent, both in binary notation. The mantissa represents the significant digits of the number and the exponent represents the magnitude of the number. The binary representation allows for efficient computation of arithmetic operations on real numbers, but can also lead to rounding errors due to the finite precision of the representation.
You can think of it as if there is a limit to the number of significant digits a number can have. 1693984725.15 has 12 significant digits, where 0.15 only has 2.
Last updated
