Index Array by array of numbers or booleans

[Hugin.]

I didn't find this idea immediately, perhaps something similar has been posted already?

I would like to propose an extension to the Index Array function, to accept an array of numbers or booleans on the index input. The picture below illustrates the idea. The new Index Array function would replace the for loops in both cases, making for a neater and more readable diagram.

[altenbach]

I guess for higher dmension arrays, only one of the indices can be wired with an array.

[AristosQueue (NI)]

Speaking for myself as a LV user: I've certainly had cases where I would have used the array of indicies syntax, but it is pretty rare. I do not find the existing syntax burdensome, but I'd use the advanced syntax if it were available. The array of bools, not so much... and there's a performance concern there (see below).

Speaking as a member of LV R&D: This idea is totally doable and doesn't seem at first glance like it would create any ambiguous syntax in the language. My concern is the same as with all of these small syntax changes -- is the slight improvement in usability for writing diagrams worth the slight decrease in readability when reading diagrams? Every node that gains another variation in its syntax is one more place where people have to go check the help to figure out what's going on. I'm inclined to see this as benign, but I'm not sure.

Speaking as both self and R&D: There's a performance concern with the Boolean version. I'm not sure we would want to encourage people to use a syntax that needlessly creates excess arrays. Yes, the compiler could *sometimes* detect and optimize this case in a build where debugging is disabled, but when debugging is enabled, that's potentially a sizeable allocation of memory for that array.

Because of that, I'd be strongly tempted instead to support this syntax instead:

You provide the array and a function that acts on *one element* of the array that is the filter you'd like to provide.

My feeling is that the syntax weight for the simple Boolean tests is light enough with the existing syntax today to not be a problem, but that the place that we should be enhancing is with general filtering.

[AristosQueue (NI)]

I came up with another objection to the Boolean option proposed -- the arrays might not be the same size. With the integer option, you have a list of indicies to keep... the number of indicies is irrelevant, and you don't have to invent semantics to cover "what happens if the arrays are different sizes". With the Boolean option, you need the two arrays to be the same size or you have to come up with special rules.

Altenbach wrote:

> I guess for higher dmension arrays, only one of the indices can be wired with an array.

Ah... and Altenbach hits on a good reason to not do this change at all... the weird syntax now demanded of higher dimension uses.

How about just leave Index Array alone and instead introduce "Filter Array"?

Filter Array could take an array input and an array of indicies (either scalar integers for 1D arrays or clusters of integers for 2D and higher). It can be polymorphic with the VI refnum option for dynamic filtering.

[Manzolli]

I like the Integer version. Cleaner and easier to understand than the "Current". Kudos for this one. I think they are two different ideas, even though very close to each other.

[ToeCutter]

Don't like the boolean one at all- it just feels like an uncomfortable 'syntax'. If you can 'index' an array with an array of boolean, there should be an equivalent to index it with a single boolean- but that is meaningless.

The top idea is a no brainer and I would support it IF it's proposed separately to the bottom one.

[dr2]

I like the top idea and Kudoed the idea for that instance only.

I'm not a fan of the second one.  If it wern't for the "Current" and "Proposed" pictures, I'm not sure I could have figured out what was going on in the second one.

[Hugin.]

Reading the comments on my proposal, I realise that the boolean array option is neither intuitive, nor efficient. Therefore I would like to withdraw this part of the proposal. Any kudos on this proposal should apply only to the first option with the numeric array.

[donkdonk]

This really is déjà vu experience 

I am pretty sure I commented on this idea.

I think it is a duplicate of my idea

Allow-booleans-for-array-indexing

This was before the loop conditional terminal was introduced.

I can see that the arrays not being equal in length, probably is a show stopper.

(I don't know how this is handled in matlab, but I do know it has a similar indexing function)

[Hugin.]

@donkdonk

"I think it is a duplicate of my idea

Allow-booleans-for-array-indexing"

I see that I didn't do my homework properly, the boolean idea was already posted previously.

"I can see that the arrays not being equal in length, probably is a show stopper."

The issue with different length arrays is not a hard problem: just handle it the same as if you do auto-indexing of two arrays in a loop, the shortest array determines the length of the selection process. Conceptually, what the function would do is to select items from an array with the true booleans, rather than deleting items from an array with the false booleans.

But I agree with AristosQueue that there is a performance issue with unnecessarily creating a bool array. And intuitively, it is quite different from what Index Array normally does, so if it is implemented it should probably be with a different node.

[Hooovahh]

This should likely be it's own idea, but can't we take and implement some of the 10+ year old OpenG array functions and make them native?  OpenG already allows for indexing with multiple indexes.  There is also a Conditional Auto-Indexing Tunnel VI that is your boolean function.  

Delete can allow for deleting multiple indexes, Sort could return the sorted indexes, sort could support 2D arrays sorting by rows or columns, in asending or decending order, reorder array, reverse 2D array, Remove Duplicates from 1D array, etc.

EDIT:  I made an idea exchange item for implementing OpenG functions, there is some over lap with this idea, sorry.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Extend-Array-Functions-to-Mirror-OpenG/idi-p/3236163