That's why I said "or". 🙂 All of the non-flat-memory types have greater overhead if a copy is required, and it scales up pretty fast and often non-linearly as memory gets depleted and finding an empty block gets harder.
There's a whole science to performance that is generally not of interest to most programmers (G or otherwise!), but becomes critical when coding library functions for manipulating potentially large data structures.
Reasonably, isn't there a limit to the number of dimensions we can expect? I'd say a 5D array would be wild. 10D for sure. Not sure if LabVIEW has a limit. Hardcoding the loops up to 20D would be silly, but possible. This would also allow an array of clusters as a return value. After 20D, the fallback could be the less efficient reshape.
Yes, .vim recursion is not possible jet. (And if you try real hard, LV does indeed crash. All kinds of expected weirdness, like popups asking to save SwapInstanceVIUnusedName2.)
I think recursive .vim's should be (theoretically, not at the moment) possible as long as the recursion is in a by default "Declined" case of a Type Specialization Structure. That would allow the editor to not have a broken VI. Then it might still go to infinite recursion at instantiation time, but it make solutions for this problem possible. The problem is (I think?) determining whether it will crash or not at instantiation time and preventing that. A luxury for me (I can live with a crash if I do stupid things), but (understandably) a requirement for NI.
>Because of the performance problems of Reshape Array, I would advise >users against using this function.
Could we not eliminate these performance problems, at least for just interpreting an n-D array, which is stored in memory as a 1D list, as the equivalent 1D array? Why is a full copy needed, rather than some subarray-type magic?
> Hardcoding the loops up to 20D would be silly, but possible.
It's a reasonable point for this particular VI. I've actually monitored for 15+ years for any VI going through my system, as I work on CARs from various customers, for any array over 5 dimensions. Never seen one yet. Not saying they don't exist, but hardcoding up through, say, 8, would push it into "I'm ok with that being a special case" territory.
If you look inside LV 2018, you'll see a bunch of new array VIMs in the shipping examples. There's some tuning still to be done, but I want to move those to the palettes in 2019 if possible. I could see putting this on the list.
The other approach would be to use an XNode, which can script as many dimensions as required. It's a pity they're not quite stable enough to release officially.
Using an XNode wouldn't change much. An XNode is automatically polymorphic, but it will not avoid having to use the "reshape array" function (in the Ability GenerateCode) ... and it is mainly this function that raises a problem.
An XNode could script as many for loops around the search as needed (or in fact script anything required). If this can be programmed manually, and XNode could do this automatically. It will be possible to eliminate the reshape.
Not that an XNode is the solution, they usually end up being a problem. And a lot of work to make... And not supported in NXG.
