Type Cast help

[TurboT]

In the LabVIEW help for Type Cast, the following statement can be found:

If the function must reinterpret data instead of transforming it, a temporary buffer is used.

What does this mean? I am converting from a DBL to an Integer (U64), and it looks to me the U64 output is the integer representation of the 64-bits that make up the DBL input variable in memory...rather than the DBL's actual numerical value. So which is this...reinterpretation or transformation? And what would be a good example of the other?

Thank you...

[Francois Normandin]

I think you'd have transformation is you went, for example, from U8 to U16 (padding)

and reinterpretation for DBL to INT where you'd have a complete reinterpretation of the value because DBL is stored as exponent and mantissa, while integers are "pure" hex values.

Check out this page and you can guess which and reinterpreted.

[Ton Plomp]

I think you'd have transformation is you went, for example, from U8 to U16 (padding)

What would be the effect (on the data) of transformation. I guess nothing:

Ton

[Francois Normandin]

What would be the effect (on the data) of transformation. I guess nothing:

Ton

Yes, that's what I meant. Transformation = no buffer copy. Interpretation = copy of data in buffer to type cast.

I see your point.

[ShaunR]

I would classify this as a transformation.

[TurboT]

I would classify this as a transformation.

So then what is reinterpretation? And why does reinterpreting require a temp buffer, and transformations do not?

[ShaunR]

So then what is reinterpretation? And why does reinterpreting require a temp buffer, and transformations do not?

Well. I would tentatively suggest the others are reinterpretation (dbl to uint64 is reinterpreting the bits to form an equivalent value).

Why does it need a buffer? Don't know Implementation specifics that I'm glad I don't have to worry about. But I would guess a temporary buffer may be required as an intermediate step in the conversion process since the new type cannot be represented by a union (c terminology) of the memory locations unlike a transformation..

And before you ask I still have no idea no idea what 4.x data is either other than a vague recollection that it was something to do with a change in internal representation between LV versions some time ago..

where's Rolf when ya need him

Edited September 9, 2010 by ShaunR

[mje]

Transformations don't require a new buffer because you're telling LabVIEW to change the way it interprets an existing piece of data. The string "8243" becomes the numbers {56, 50, 52, 51} or {0x38, 0x32, 0x34, 0x33} because it is the U8 representation of the same data the string contains. Cast to a U16 and you get only a two element array {14386, 13363} or {0x3832, 0x3433}.

Now I'm a little unsure about reinterpretation. It makes sense to me that a temporary buffer would be used if the two types don't occupy the same physical number of bytes, otherwise memory would start leaking all over the place. Make our string "82437" and our U8 data is as expected since the sizes align and can be made to match, {0x38, 0x32, 0x34, 0x33, 0x37}. Cast to a U16 though and we now have alignment issues that cause size mismatches, the cast returns {0x3832, 0x3433}. We've lost our last byte of data. I'd expect this is a re-interpretation?