05-01-2018 01:18 PM
I wonder if this has anything to do with LabVIEW using banker's rounding?
05-01-2018 01:37 PM - edited 05-01-2018 02:01 PM
@TomOrr0W wrote:
The post from billko made me go back and look again at the code I ended up with to see if it would be a better fit. While typing in timestamps, I noticed the below behavior.
It turns out the Timestamp doesn't actually Truncate. There are a certain number of individual times where a timestamp less than a certain time rounds up to that time instead of down to the time 1 ms prior. See the attached vi.
You might be running into something I found a few months ago, when we were discussing other weirdness related to timestamps. See my post here: https://forums.ni.com/t5/LabVIEW/TimeStamp-to-Text-Insanity/m-p/3746249/highlight/true#M1054587
Basically I found that if you configure a timestamp indicator or control to show more than 19 digits after the decimal point, what it shows for the fractional part is basically garbage and not related to the actual value in the timestamp. I think it's a bug in LabVIEW, and the workaround is to never try to display more than 19 fractional digits.
Edit: Looking a little more closely at what's happening, it seems like if you display 20 digits, then LabVIEW adds approximately 1/8 (0.12499...) or 2^-3 seconds to the value in the timestamp before displaying it. If you display 21 digits it adds 1/64 (0.01562499...) or 2^-6 to the value before displaying it, displaying 22 digits adds 1/1024 or 2^-10, displaying 23 digits adds 1/8192 or 2^-13, displaying 24 adds 2^-16, 25 adds 2^-20, 26 adds 2^-23, and so on. Except for the jump from 2^-6 to 2^-10, it seems to follow a pattern. However, if you go all the way up to displaying 39 digits, suddenly it adds almost 1/4 (0.24999...) or 2^-2 to the value before displaying it, 40 digits adds 1/32 = 2^-5, 41 adds 1/512 = 2^-9, 42 adds 1/4096 = 2^-12, etc. The moral of the story is, don't try to display more than 19 digits of precision on a timestamp or it'll have something extra added to it before it's displayed.
05-01-2018 02:12 PM - edited 05-01-2018 02:26 PM
@TomOrr0W wrote:
The post from billko made me go back and look again at the code I ended up with to see if it would be a better fit. While typing in timestamps, I noticed the below behavior.
It turns out the Timestamp doesn't actually Truncate. There are a certain number of individual times where a timestamp less than a certain time rounds up to that time instead of down to the time 1 ms prior. See the attached vi.
The problem doesn't really relate to the Timestamp Datatype. The datatype is simply far more granular the the theoretical maximum resolution of the SI Second as it is currently defined.
1.087827757077667e-10Sec that is the period of one transition between the two hyperfine levels of the ground state of the cesium 133 atom you only get integer number of transitions! and, a U64 divides a second into about 2e19th parts. Now, if you have a bunch of cesium clocks, you can arerage them, and weight those individual clocks based on a whole bunch of variables somewhere in France and derive about 1e-12 seconds as a long term accuracy for the SI Second but that takes a large group of dedicated physicists.
(Where is Block when you need a discourse on atomic fountains?- yes, that's what his avatar is- an atomic fountain)
05-01-2018 02:36 PM
@JÞB wrote:(Where is Block when you need a discourse on atomic fountains?- yes, that's what his avatar is- an atomic fountain)
Did you mean "Blokk"? His avatar looks like a puppy, to me ...
BS
05-01-2018 02:52 PM
@Bob_Schor wrote:
@JÞB wrote:(Where is Block when you need a discourse on atomic fountains?- yes, that's what his avatar is- an atomic fountain)
Did you mean "Blokk"? His avatar looks like a puppy, to me ...
BS
IBD I guess he changed it
05-01-2018 02:53 PM
Hi arteitle,
From the 32 bits your thread mentions LabVIEW actually using, you should only count on displaying 9-10 digits (nanoseconds - hundreds of picoseconds).
This should never be a problem, as I don't display (or use string formatting codes) for anything beyond 3 digits in normal work. This large number of digits would never be displayed to a user.
Today's post about it not always truncating is more a curiosity than anything. Adding half a millisecond before displaying the time will work fine even if the result is a couple tenths of a millisecond above or below the boundary.
I wonder if the weirdness you mention is computer-specific. I don't see any strangeness of that nature until I get to 78 digits displayed with LabVIEW 2015 on a Windows 10 VM.
05-01-2018 03:43 PM
The fractional part is stored in 64 bits and as the documentation says, that provides 19 digits of precision. You're right, the misbehavior I described is version-specific, I only see it on the 64-bit version of LabVIEW 2017, not on the 32-bit version.