Have you benchmarked it? Seems to me Copying\Rebuilding\Reshaping that array could be expensive! Not sure if the reshape can be avoided.
The Build Array just so Get Array Size returns an array can be avoided. Simply get the size of the array (returns scalar or 1D array) and concatenate with an empty 1D array (or an array with 1 constant to get the same result).
"The Build Array just so Get Array Size returns an array can be avoided. Simply get the size of the array (returns scalar or 1D array) and concatenate with an empty 1D array (or an array with 1 constant to get the same result)."
Because of the performance problems of Reshape Array, I would advise users against using this function. I definitely would not support shipping it with LabVIEW -- even if it works for some users in small array cases, library functions have to consider their behavior at all scales, and this one fails quickly -- anything with multiple dimensions is tending toward large even for small dimensions (3x3x3... 4x4x4... gets big fast). The data movement would be substantial, and possibly full copies if the input isn't available for modification -- a bad thing in a function that should not be modifying the data.
Overall, in my opinion, it would be misleading to put a function into the palettes that looks general purpose but is actually very limited use.
Any app that needs a search of an N-dimensional array would be far better served by dropping N-1 For Loops around Search 1D Array. Also, the output could then be a cluster -- generally more useful syntax for multiple indexes.
Yes. But at the moment, the only way I know to write this function efficiently is as a primitive. LabVIEW's VIMs don't allow recursion. There's some fun things we could do if they were recursive, if only we could detect infinite recursion before it killed LabVIEW.
Detecting "recursion is infinite" runs smack into the Turing halting problem, and even special cases become intractable if you start nesting VIMs. There's probably some things we could do to make many (most?) of the useful cases viable, but we haven't put effort into that at this time. It's on the research backlog.
PS: For anyone looking at my previous post and wondering "What is that weird structure node is that looks like a cross between a case structure and a diagram disable structure with the four colored boxes in the selection ring?" ... that's an unreleased feature of LV 2017 that we were experimenting with that is actually productized in LV 2018 called the Type Specialization structure. You can find it on a couple of 2017 block diagrams. It's execution behavior is stable in 2017 (which is why we could use it in a couple small cases), but it's editor behavior is not and it has some issues with nested VIMs, so play with it at your own risk. It'll all be cleaned up in 2018 if you wait a few months.
ouadji -- that's an array of numerics, I'm guessing. Try an array of non-empty strings (or paths/objects/waveforms/clusters of arrays). I had a similar VI optimization problem recently where the complex types introduced a 1000x performance hit on the reshape vs the direct access.
