From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
How can I subtract timestamps to give me a DBL time in seconds?
@LesHammer wrote:
True - in fact that would get rid of those conversion dots on the subtract widget of my program. 🙂
No. Do not add coercion bullets. The coercion that the Subtract node is doing is not a coercion to double. It's an under-the-hood conversion that shouldn't, in my opinion, be reflected on the block diagram. If you coerce to double first, you will get the wrong answer. Coercing to double gets you a timestamp that is almost right, but not quite. You will be off by fractions of a second. It's small, but some users care about very small amounts.
These two outputs are NOT the same.
@AristosQueue (NI) wrote:
@LesHammer wrote:
True - in fact that would get rid of those conversion dots on the subtract widget of my program. 🙂No. Do not add coercion bullets. The coercion that the Subtract node is doing is not a coercion to double. It's an under-the-hood conversion that shouldn't, in my opinion, be reflected on the block diagram. If you coerce to double first, you will get the wrong answer. Coercing to double gets you a timestamp that is almost right, but not quite. You will be off by fractions of a second. It's small, but some users care about very small amounts.
These two outputs are NOT the same.
What prompted you to post to an 18 year old topic? 😄 I mean, this is good info, but...?
@billko wrote:
What prompted you to post to an 18 year old topic? 😄 I mean, this is good info, but...?
If I would have a guess, he was working on something in LabVIEW and searching the forum for related posts and stumbling across this. And found this important enough to mention. Also I would agree with his assessment that this should actually not cause red coercion dots to appear.
Yes this function has to do a conversion eventually as is shown by the different output result type of it but no it is not a coercion really. It does not force the inputs to double to do its conversion but rather calculate the fractional and integer part of the timestamp difference separately and then combines them to the actual result which happens to be a double. The important bit is that the conversion to the double happens after the arithmetic operation NOT before, so the full precision of the double numeric space can be used.
And this definitely can matter. The timestamp only uses 32-bit of the fractional 64-bit currently (well last I checked which is a few years and that still is less than a ns resolution (1/2^32)) and to represent the current date it also requires 32-bit of the integer part and that will be 33-bit somewhere around 2037.
A double only has 52-bit of mantissa bits and 64 bits in total so if you do a conversion before the arithmetic operation the fractional bits are immediately reduced to about 20 bits of the 32 possible bits which is only about 1us resolution anymore and then the subtraction is performed. If the subtraction is done in integer space and then converted and the difference is small the result is then accurate to the full 32-bit that the fractional part of the timestamp offers.
