Strict Variant <-> Numeric conversion

[mike5]

Is there a way to get the real numeric type from the Variant, so that it can correctly be cast to either Int or Double? Variant To Data silently converts for you, and I don't want that...

Br, Mike

[Ton Plomp]

The OpenG variant tools supply that info.

Ton

[hooovahh]

Never knew that OpenG had that function. I did find what appears to be the same functionality in the vi.lib.

<LabVIEW DIR>\vi.lib\Utility\GetType.llb\Get Type of Variant.vi

Found that when digging around the TDMS viewer. Using some more code from the viewer you can convert many data types to string.

[mike5]

Thanks! I'll be putting it to some good use

[mje]

Also check out vi.lib\Utility\VariantDataType\*. There's a lot of useful VIs in there. Specifically for your case, GetTypeInfo.vi.

[eberaud]

Reviving this topic instead of creating one... vi.lib\Utility\VariantDataType\VariantType.lvlib seems to be similar to vi.lib\Utility\GetType.llb

 

Is there a reason for both to exist? Is there an old implementation (the llb) and a new implementation (the lvlib)?

 

This whole concept seems very important to understand, I would like to get to the bottom of this.

 

Thanks

[mje]

The llb is older. I can't remember when the lvlib came around, but it's been around for several versions now.

I can't say I'm familiar with the old implementation, but I've used the newer one extensively. Works great.

[Darren]

The GetType.llb VIs were added in LabVIEW 7.0, and they were used to parse the legacy I16 Array type descriptors. 

 

The VariantDataType VIs were added in LabVIEW 8.0, when we switched to using Variants to define data types instead of I16 Arrays. At this time, the internals of the old GetType.llb VIs were updated to use Variants as well.

 

So there's no need to use the VIs in GetType.llb. They are deprecated. And it's a little late in the game, but we are planning on marking them as deprecated in a future LabVIEW version.

[eberaud]

Great, so I can focus on the lvlib only. Thanks for the info 

[hooovahh]

Yes OpenG also has their versions of getting data type of a variant.  It bugged because in version 2011 the OpenG version was about 10 times faster than the NI version from the lvlib, but in 2012 and newer the NI version was about 10 times faster than the OpenG.  At one point I had some goofy code that would know the version and pick the right one, but I convinced myself it wasn't worth it and to just go with the native (NI) solution whenever possible.

[eberaud]

The OpenG does have feature that the NI lvlib doesn't though, like getting the values of the elements of an array. The lvlib GetArrayInfo.vi only gives the element type of the array. So my code uses OpenG when necessary, and VariantType.lvlib when possible, in order to use as much native NI code as possible.

[drjdpowell]

The OpenG does have feature that the NI lvlib doesn't though, like getting the values of the elements of an array. The lvlib GetArrayInfo.vi only gives the element type of the array. So my code uses OpenG when necessary, and VariantType.lvlib when possible, in order to use as much native NI code as possible.

 

Yes, it’s important to note that NI provides a VariantType library, rather than a full Data library like OpenG does.  I wish NI would add the necessary VIs to make its library a complete VariantData solution.  I’ve been toying with the idea of doing it myself.

[hooovahh]

The OpenG does have feature that the NI lvlib doesn't though, like getting the values of the elements of an array.

Are you referring to the Index Array under the VArray palette?  I'd recommend using a Variant to Data converting the variant, into an array of variants, then you can use the native array functions to index the values out of the array.

[drjdpowell]

Are you referring to the Index Array under the VArray palette?  I'd recommend using a Variant to Data converting the variant, into an array of variants, then you can use the native array functions to index the values out of the array.

Variant to Data will also convert a cluster to an array of Variants; something I did not know for a long time.  

 

— James

 

PS> A related idea.

[hooovahh]

That was a fun little XNode and didn't take much time at all.  More people should know about the neat features of Variant to Data when it comes to arrays and clusters.

[eberaud]

This is really cool. This quick test returned TRUE and TRUE! I guess the Variant to Data didn't exist at the time the OpenG library was made...

[hooovahh]

I know these existed in 7.x, not sure about 6.x or 5.x which is when most of the OpenG stuff was made.  Still it is possible it existed, but because it was a relatively new function, maybe the OpenG community didn't know of its full potential.

[eberaud]

I see. One thing that still requires OpenG though is the reshape array functions (MultiD --> 1D and 1D --> MultiD). Are you aware of any native LV code to replace those?

[hooovahh]

The Reshape Array can do that, but you'll likely need some extra math to determine the size of each dimension.  But what is wrong with the OpenG solution?

[eberaud]

I mean the Reshape array that takes a variant as an input and generates another variant as the output, the data manipulation happening on the type descriptor side. The OpenG lib seems to be a bit old, plus you said that it sometimes perform 10 times slower than the LV lib. So I try to avoid it when I can...

[hooovahh]

I wasn't trying to say all OpenG functions are slow.  You should perform your own testing to determine if they work fast enough for you.

 

In any case I started making two XNodes to go from 1D to MultiD array and back but I realized it was much easier to just make a VI that works well enough.  Attached is a VI that goes from MultiD to 1D and back in a way that I think is pretty efficient.  The only thing I'd try to improve is a better way of knowing an array size of the array.  Also this method only supports up to a 5 dimension array.  Feel free to add more, but a better solution would be to do it programatically with an XNode.

Array Dimension Converter.vi

[Rolf Kalbermatter]

This is really cool. This quick test returned TRUE and TRUE! I guess the Variant to Data didn't exist at the time the OpenG library was made...

 

It existed at least in 6.1 but you have to consider that while the node maintained appearance and principle operation, its implementation was many times improved to handle various more complex data transformations.

 

Initially it didn't do much more than transforming a variant that was a pretty exact representation of the target data.

[hooovahh]

consider that while the node maintained appearance and principle operation, its implementation was many times improved to handle various more complex data transformations.

That's a very good point.  Variants are the first real example of a loosely coupled data type, in LabVIEW, a strictly typed language.  I mean sure you can express any data type as an array of bytes, and therefor a string.  But still Variants are an interesting thing that I'm guessing had some internal debate at NI on if and how they should be implemented.

[eberaud]

Initially it didn't do much more than transforming a variant that was a pretty exact representation of the target data.

 

Yes this is what I thought the whole functionality was. Thanks.