Allow unwired index for "Array Index/Replace Elements" on the In Place Element Structure

[GregSands]

This would replicate the ability of the standard Index Array function to extract a subarray from a multi-dimensional array. Currently both indices must be wired, which only selects scalar elements.

Another related enhancement that may be useful is to provide the equivalent of "Array Subset" on the In Place Element Structure.

[Manzolli]

Nice idea!

[fabric]

This is an excellent idea! I can't imagine why the Index/Replace wasn't implemented like this in the first place... 

I agree that the "Array Subset" feature would be an obvious candidate too if this idea ever gets accepted 🙂

[ghighuphu]

The funny thing is, that the VI Analyzer marks an "Index Array" function wired to an "Replace Array Subset" function as a medium-rank failure. See example below.

[Intaris]

But won't this only work well for a single dimension?

When you know how the data is stored in memory, depending on whether the array has been marked as transformed or not this would work efficiently only for either the first or second dimension surely.

NI would have to be able to treat the other dimension as a "Sparse" array (i.e. each element being further apart from each other than the actual element size) which, should it actually be implemented, would lead to lots of other lovely things.... (Array of clusters to element arrays in-place and so on.... )

[AristosQueue (NI)]

Intaris is partially correct.

The LV compiler already has the ability to take a sparse slice out of an array without data copy. In fact, we do that when you use the regular Index Array node to extract an array. See the context help (note that the VI must be fully compiled with no unsaved changes to see the subarray notation, since the compiler makes that evaluation late in the game, and it can't be something that gets constant folded). So that isn't the problem.

The problem is that the In Place Element (IPE) structure cannot maintain its contract to handle the memory in place unless we put a lot of restrictions on what you do with that array. For example, you would not be able to wire the array to a Build Array to append elements onto it because that wouldn't be maintaining the invariant of the IPE. Nor would you be able to pass it through any subVIs because they might do something to the size of the array (I suppose we could do it with fixed-sized arrays on FPGA, but that's a pretty limited use case). Explaining why wires break in these cases would be tricky at best.

[Darin.K]

What wires are breaking currently in the IPES?  I can do a row replace using the classic three-way split and the Array Subset/Replace node.  Notice that I can flagrantly try to violate the inplaceness by trying to replace 1 row with 2 with nothing breaking.  (I left out the case structure to check for row < 0 in this example).  In this case the second row of the replacement is simply ignored.

You can similarly try to replace with an empty array and it will be zero padded to fit.  It is all natural.  I like this idea as a way to simplify the syntax for the above code, pad/trim the replacement elements to fit in the current array.  Someday the compiler may be smarter and recognize more array replacement operations as in place, right now it is very easy to trick the compiler into thinking a copy is required.

If I try to stuff 20 pounds of you-know-what into a 5 pound bag this idea makes it easy to wind up with only 5 pounds.  Right now the compiler is happy to give me whatever size bag is necessary, and that just means I sometimes wind up with an extra 15 pounds of stuff.

[Intaris]

@AQ

Does this "sub array" work in both dimensions?  In one dimension it would be a contiguous range of memory whereas int he other it would be "sparse".

Why then if we have an array of cluster of DBL, I32 and Boolean can't we simply access the booleans as a normal array without unbundling and bundling.....  This is essentially the same operation in the background, right?

[Bob_Schor]

I posted a similar request a few days ago, having just discovered that the Index Array/Replace Subset In Place Element didn't work "as advertised" in the Help document for multi-dimension arrays.  One could argue that the Help document in LabVIEW 2016 only hints that you should be able to replace, say, a row, but if you look at the Help for the same function in LabVIEW 2012, it explicitly says you can use this to replace rows, columns, pages, etc..  So at the very least, fix the documentation to make clear this only works for a single element, regardless of the dimensionality of the input array.

Bob Schor