The Type Cast function should accept higher dimensional arrays as inputs

[altenbach]

As discussed briefly here, the Type Cast function has a seemingly unecessary limitation that it does not accept arrays with more than one dimension.

Obviously, such arrays cannot be valid inputs for the "type" terminal (and thus the output), because of ambiguity (For example if we have a8 elements, LabVIEW would not know if we want a 1x8, 2x4, 4x2, or 8x1 2D array). However, having a multidimensional array as input does not pose any such problems and the result can be fully predicted. If such arrays are allowed as input, we could do cool things very quickly and with very little code:

Some examples (currently not possible! :()

• Type Cast a 2x2 2D U8 array to a SGL or I32 scalar, for example.
• Type Cast a 4x4 2D DBL array to a 1D CDB array of lenght 8.
• Reshape a 3D DBL array to a 1D DBL array containing all elements (see image below for what we need to do today instead)

 

IDEA: The input of Type Cast should accept almost anything. In particular, numeric arrays with more than one dimension should be allowed and simply interpreted in memory order.

(Of couse certain things should probably remain disallowed as inputs, such as arrays of strings, for example.)

[AristosQueue (NI)]

They can't be reinterpreted -- they have to be fully reallocated because of the length bytes for the missing/added dimensions. That's why Reshape Array exists. Now, I would certainly be on board with making a smarter Reshape Array, but I don't think changing Type Cast is the way to do it.

[altenbach]

Thanks. Yes, as a first step "reshape array" should be smarter and allow one unwired size input, which would be assumed to be the balance of the total number of elements and the other size inputs, rounded up to the next integer. Here is an old related idea with lots of discussions.

I am not too familiar with the reallocation requirements, but couldn't the starting point just be moved up without touching the data, or are we running into alignment problems? 

Note that "flatten to string" works just fine with inputs of any dimensions, and if we don't prepend the size, the resulting string is exactly what we would need to cast into the new 1D array.

Does Type Cast never make a copy currently?

[Intaris]

Type cast with Enums most certainly DOES make copies.......

[SteenSchmidt]

@AQ: As altenbach's suggested Type Cast only ever goes down in dimension size, couldn't the memory from the original array be reused (if the Type Cast is the singular user of the input array)? Out of lazyness I haven't dug through the whitepapers, before posting this, to find the actual memory layout of multi-D arrays in LabVIEW, but I'd assume they're laid out something like this (as LabVIEW doesn't support sparse nor jagged arrays):

<type_descriptor=array><dim_count><dim_0_size><dim_1_size>...<dim_n_size><elem_0>...<elem_m>

Then, if you Type Cast to a 1D-array you could retain the original <elem_0>...<elem_m> chunk in memory, and just write a new prologue before that on top of the old prologue (<type_descriptor=array><dim_count=1><dim_0_size><elem_0>...<elem_m>).

The relocated pointer to the new 1D-array is easy to calculate at edit time, and you'd have a smaller chunk of fragmented memory than after a copy. In this situation you can ommit the malloc, which is a good thing. I would have assumed the LabVIEW mem manager already did what I'm suggesting here, but your comment (regarding Reshape Array) seems to suggest otherwise?

Regards,

Steen

[AristosQueue (NI)]

Steen: Might be able to do something with a subarray wrapper if we allow Type Cast to allocate a subarray with a stride of 1. That would work if the next operations were reading/writing elements of the array. But as soon as you hit any operation that concatenated the array or displayed it on the panel or (as of LV 2012 but probably not LV 2016) pass it out of a subVI, it would have to fully reallocate. Munging the array directly like you propose would not make it amenable to downstream handling. Remember that arrays are passed around as handles. The pointer-to-pointer has to point to the first dimension followed directly by the data.