time stamp size

[modicon]

Just a generic trivia question... after saving some >10Meg data files which included timestamp data, I discovered that I could save a bunch of room by saving the times as DBL instead of TS.   SInce only 64 bits of the 128bit TS contain all the information, I was just curious why such an airy structure was needed. (Are there attosecond timing boards on the horizon for NI in the future.?)

Is there any reason for saving the time data as TS instead of DBL?

[altenbach]

---

modicon wrote: Is there any reason for saving the time data as TS instead of DBL?

---

A timestamp is 128 bits. See How LabVIEW Stores Data in Memory for details. If you .e.g. only need a one second resolution you can use DBL.

[altenbach]

Also, if you are only interested in relative times, the difference between two timestamps is only DBL.

[Jarrod_S.]

Note: I'm not an expert here, but this is what I know...

Timestamp data is fixed-point, whereas doubles are floating-point numbers. Floating-point numbers have the potential problem that it can be impossible to reliably compare two floating-point numbers. You can't always be exactly sure whether two numbers are the same, or which is greater. Obviously 1.0 > 2.0, but there are situations with very close values where the imprecision renders the comparison inaccurate.

This would not be a good solution for dealing with time. There could be situations where you didn't know exactly which event happened first, or if they happened at the same time. Suppose you are sending packets of data from one place to another, and using the timestamp to keep them in order on the receiving side. How couldy you know the ordering is correct?

Fixed-point numbers sacrifice efficiency in calculations and overall numeric range to overcome this problem. Luckily with timestamps, you generally don't require that huge of a numeric range. A few thousand years of time is generally sufficient. Also, the arithmetic used with timestamps is less rigorous than general-purpose floating point arithmetic.

Hope this makes sense.

[modicon]

Actually, I've discovered if you only require 1-second resolution, you may cram it all into a SGL.  Convert the TS to a DBL..convert the DBL to U32 ...cast the U32 to SGL.
I now use this to store a long array of SGL data with the time as the zeroth element.  My data comes from PLC's  anyway, and I can only  update every two or three seconds at best....  I like being able to manipulate big 2D arrays of SGL a lot nicer than big 1D arrays of clusters.

[altenbach]

---

@modicon wrote:
...cast the U32 to SGL. ...

---

OK, this make so little sense, it's scary. Why would you cast a U32 to SGL??? What's wrong with keeping it as U32? 😮

[modicon]

...I cast it to a SGL so that I may conveniently prepend it to my control process [SGL] array.  Since my data is in this form,  I can use Write File+ [SGL].vi to very simply dump it all to a file.
If I merely coerced the DBL to a SGL, I would be throwing away data and would only have ~15min resolution.  If you look at the DBL-to-U32 conversion, all you lose is the stuff to the right of the decimal point.  Since the U32 at that point is the same 4-byte size as a SGL, I can save all the bits by casting to a SGL, but I hafta decode it back when to retrieve the time value from the array.

[altenbach]

OK, if you never look at the SGL value and only use it for storage before casting it back, it should be OK IF you never exceeed the range of the 32 bits. But.... You are creating the Y2K problem all over again. For example if your year is past ~2040 all your code will mess up! Try it!

You are throwing away a lot of data going from 128 to 32 bits. can't you store relative times in seconds directly as SGL instead? You'll have a 23 bit mantissa, which is a lot of seconds. 

[modicon]

....well...I dunno...2040??.....I suppose in some vain way I would like my datasets to outlive me for 20 years before going bad...but in that far horizon I am sure, Labview, Windows, and PC's will all be just virtual historical photon traces on the Syndotic:GroupMind.ancient[memeThunk]...

[Jarrod_S.]

My guess is that if Microsoft invents these Syndotic:GroupMind.ancient[memeThunk] things you speak of, they will doubtlessly be backwards compatible through around Windows NT, meaning someone somewhere may yet want to run your code using the virtual historic photon trace emulator. Just keep in mind, none of this will be Y3K compatible 🙂