From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
altenbach

More array operations should support timestamps (threshold, interpolate, etc)

Status: New

(This is different and less controversional than  this related old idea)

 

Arrays of timestamps only contain legal values and can even be sorted. We can use "search 1D array" to find a matching timestamp just fine.

 

As with DBLs, there might be a very close array value that is a few LSBs off, but well within the error of the experiment so it is sufficient to find the closest value. We can always test later if that value is close enough for what we need or if "not found" would be a better result.

 

If we have a sorted input array, the easiest solution is "threshold 1D array" giving us a fractional index of a linearly interpolated value. For some unknown reason, timestamps are not allowed for the inputs, limiting the usefulness of the tool. One possible workaround is to convert to DBLs, with the disadvantage that quite a few bits are dropped (timestamp: 128 bits, DBL: 64bits).

 

Similarly, "Interpolate 1D array" also does not allow timestamp inputs. In both cases, there is an obvious and unique result that is IMHO in no way confusing or controversial.

 

 

 

IDEA Summary: "Threshold 1D Array" and "Interpolate 1D Array" should work with timestamps.

 

 

 

3 Comments
JÞB
Knight of NI

I like the idea but its going to provide some challenges.  If my mind is not all wonky, the Timestamp is two I64's so a conversion to dbl is going to be lossy.  Coersion to extended complex might offer a platform dependant solution that works %95 for the users needs.  Yet that brings in even more issues with comparing complex numbers!  ARGH! Math should be simpler!

 

I'd love to hear NI opinion on this.


"Should be" isn't "Is" -Jay
altenbach
Knight of NI

Yes, that's why the primitives need to work on the 128 bit timestamps directly, avoiding a loss in information as I outlined. Coercing to any floating representation, even EXT,  is not acceptable.

 

(It is actually a signed and an unsigned part, see here).

 

Note that all comparison operations, sorting of arrays, etc. are natively supported in LabVIEW for timestamp data, so most of the guts are already in place. Some of us even made high-byte count math tools for the varios coding challenges (factorial, vampire numbers) and it seems rather trivial to implement something that can handle 128bit signed timestamps. It's just bits! 😄

 

 

JÞB
Knight of NI

@CA- I DID say I liked the idea:D

 

I just want the edge cases well documented!  I believe we agree there will be edge cases.


"Should be" isn't "Is" -Jay