Trying to avoid coercion...

[Dave_Kaufman]

I have two very large data sets (3D arrays).  One contains SGL's and the other contains I16's.  I want to perform the same statistical analyses on each data set.  I of course could duplicate the code needed to perform the analyses, but this seems rather inefficient when this type of thing seems tailor-made for a sub-vi (i.e. code re-use).  What I can't figure out is how to use a sub-vi that will use the proper data type.  No matter what I do, the I16 array gets converted somewhere to SGL, resulting in an out-of-memory condition.  I've tried the OpenG tools using variants, but somewhere along the way, a case statement is needed to convert the variant to data, and the output tunnel will cast the I16 array as SGL.

Any ideas?

[shoneill]

Isn't this exactly the kind of thing which can be solved with Polymorphic VIs?

You can implement the analysis for I16 anf for SGL, and depending on what you wire, the correct version will be used.

On another topic, depending on the nature of your data, it might be beneficial to process only one column/row at a time, limiting the coercion to a much smaller data set.  The conversion to SGL and back to I16 will then have a much smaller memory footprint, and shouldn't cause an out of memory error.

Just two quick thoughts on the subject......

Shane.

[CoastalMaineBird]

That's hard to answer without knowing more about the particular analysis you're doing.

Can you do the analysis piecemeal? If you could break off a chunk and process that, then another chunk and process that, and at the end process all the chunk results together, then you could avoid having to convert the whole bloody thing at one time.

You could duplicate the analysis code and have an SGL version and an I16 version.

If the SGL array does NOT cause memory exhaustion, then maybe you could do the I16-->SGL CONVERSION piecemeal.

Are you using a system library in the analysis? Most of those are DBL, if you're trying to save space by using SGL, you may be hurting yourself (because it has to convert to DBL somewhere inside).

If you can convert to SGL (or DBL) earlier in the process (as you're turning a 2-D into a 3-D, or even earlier), then you're more in control.

Tell us what analysis you're doing, and what VIs you're using.

[DFGray]

LabVIEW is strictly typedefed, so you cannot use exactly the same code with two different data types without converting one or the other.  Your best bet is the polymorphic VI route, as mentioned in an earlier post.  Unfortunately, almost all LabVIEW internal analysis code uses the DBL data type, so if you use any canned routines, your data will get coerced to a DBL.  Just one of the unfortunate side effects of safety and ease-of-use...

[Dave_Kaufman]

So, I decided to go the poly route, and it works fine, although the code still is duplicated in the poly's assigned vi's.  I figured this was the way I'd have to go, but, as DFGray said, there seems to be no way around the LV strict typedef.  Oh, well.