LabVIEW
Rounding error in timestamps
Solved!
In the image above, I display the same number 4 times. Numeric is a DBL, TimeStamp is a timestamp 😊. Which displays 4 digits of precision, the "2" indicators display 7 digits of precision. And you can see that the "Time Stamp" displays a 6 where it should display a 7.
I think there's a display bug, unless I'm wrong. As it is, it doesn't particularly bother me, but in principle it's mathematically wrong and therefore serious (if you take into account the rounded value on the display, the number is always correct.
I've seen this bug on a particular value, I haven't tried it with other values. I'm using LabVIEW 2019.
If I'm not mistaken, I think it's necessary to find out, and even to send it back to NI for the bug to be corrected, unless it's already been corrected.
How did you even get the time stamp control to look like that?
When you put one down by default it looks like this:
I'm assuming you have some sort of custom formatting set up... what's the format string being used?
When I display a number or a timestamp on the screen, it's not to display all the possible decimals, I display what's necessary. So OK, the example shown was in µs, which isn't much (but on a MIL-STD-1553 bus it counts). But it's valid with only one decimals:
It's the same number, and whether it's displayed in a DBL or Timestamp datatype indicator, displayed in "relative time" or "absolute time" format doesn't round it off correctly: it seems to me that it's mathematically wrong.
Of course, if you take the variable and use it to make calculations, they will be correct because the display format is only for display purposes; but when I'm in front of my screen I only see what's displayed, so in this case I'm seeing a false value.
When you look at your watch and you see 8:59 and you've got an appointment at 8, do you say to yourself that it's still 8, so I'm on time for my appointment? (as I'm a specialist in being late, the next time I'm late I'll say: "hey, it's a timestamp, I don't want to round it up 😊").
Rounding up a current timestamp would display a time that's actually in the future. Nobody can predict the future. 🙂
Your analogy somehow is flawed,.if arriving at 8:59 is 59 minutes to late for the appointment you should have in the first place shown the timestamp with minutes too. Or would 8:29 be perfectly on time in your example? 😀
The shown precision is important and something you as designer need to decide. If minutes are important you need to display them. Typically you display numerics with one decimal more than what is required by the task at hand. Ok some people like to display their numbers always with 6 digits after the decimal point simply because they can, thinking “more is better”.
@M.Julien wrote:
The things said here are true, but it still feels as if the examples shown here should show 46.7 (certainly for the second one, where it's relative time and not a timestamp). It seems like the behavior is to always floor when showing one of the time formats.
Does anyone have a good suggestion for why the displayed behavior would be correct? Altenbach's tongue in cheek remark about not getting times which haven't happened yet could possibly be a reasonable explanation.
@tst wrote:
@M.Julien wrote:
The things said here are true, but it still feels as if the examples shown here should show 46.7 (certainly for the second one, where it's relative time and not a timestamp). It seems like the behavior is to always floor when showing one of the time formats.
Does anyone have a good suggestion for why the displayed behavior would be correct? Altenbach's tongue in cheek remark about not getting times which haven't happened yet could possibly be a reasonable explanation.
My best guess is incompetence. A lot of people who write code aren't very good at it.
