Replace Array Subset with ability to replace block of data instead of single elements/row/column

[bmangum]

Currently when replacing an element/subarray using Replace Array Subset, you are only able to replace an element that is of lower dimensionality where one dimension is unity.

For example, given an array of size 100x3, it is only possible to replace one row at a time 1x3.

It would be helpful for me to avoid using a loop and be able to replace a subarray of dimension Nx3 where  100 > N > 1.

I may still have to use a loop to completely fill an array, but the loop could potentially run many less iterations.

This comes up for me because I read the FIFO buffer from a device and generate a chunk of data at once.

I then need to insert this data into a preallocated array (avoiding buildarray or similar due to the time critical nature of VI).

If I have a 1E5x3 array that I want to place into a 1E8x3 array, why waste time with a loop to do each row at a time (remembering that the loop is still much faster than buildarray)?

[Darin.K]

Agreed. Set Submatrix is a tempting workaround since I usually use DBL data. If you read the help (as of LV10) it says you get an array out if you input an array, but it does not take long to discover that is a filthy lie and the output is coerced to a matrix. Also it makes you do all of the math to specify the range of rows and columns. I'd prefer to specify the starting point and use the Submatrix size. Other than that, a great function. 🙂

[kegghead]

" I may still have to use a loop to completely fill an array, but the loop could potentially run many less iterations." Yes, but copying data with more than one dimension requires those iterations. Arrays are continuous. If you copy a 3x3 array into a larger 2D array, you're actually copying to three distinct continuous segments (the exception being if you begin to replace dimensions in their entirety). The functionality you describe would indeed be convenient, but I wouldn't expect any difference in execution: the iteration is required whether you make it edplicit with a loop or not by letting a primitive hide it.

[AristosQueue (NI)]

kegghead: It is only contiguous in one dimension. If you replaced multiple complete rows, that's contiguous, but not multiple complete columns.... or is it vice versa? I always have to go look it up, and most users wouldn't know one from the other. The node you propose would only have benefit in one direction.That doesn't make it a bad idea... I just want to be sure when we talk about the advantages, we're being honest.

The real virtue would be for the ease of reading on the diagram. The performance benefits would, in most cases (wrong dimension or small arrays [less than hundreds of elements]), be negligible.

[Darin.K]

I'm with AQ on this one, there is typically only a modest improvement in performance with a primitive over the optimal LV equivalent. The real benefits are (1) said optimal solutions are often hard to read and unknown to beginners (2) Automatic type adaptation built in (3) in general when you use a primitive you are letting LV know *exactly* what you are doing and the compiler can optimize accordingly, and most importantly to me (4) it seems like natural and intuitive behavior for that node.

[altenbach]

> Currently when replacing an element/subarray using Replace Array Subset, you are only able to replace an element that is of lower dimensionality where one dimension is unity.

Your problem does not really exist!

All you need to do is wire both (all) indices to replace a subset with the same number of dimensions as the target array:

 

I would say this idea is "already implemented". 😄

[Darren]

See comment from altenbach in the idea thread on how to implement this with the Replace Array Subset function with both row and column indices wired.