Allow booleans for array indexing

[donkdonk]

Allow boolean for indexing.

This way a quick array selection can be made without the need for building loops.

(for those familiar to matlab: matlab indexes like this)

[tst]

This is a duplicate of this idea - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-auto-indexing/idi-p/918682#A123

Also see this idea for another version -

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-quot-Concatenate-Indexing-quot-option-for-arrays...

[donkdonk]

@tst,

The idea you are referring to still needs a loop structure.

My proposed idea is to expand the current index array node to accept booleans, which is different from the idea you are referring to.

I agree the ideas are related (I did not find it when I submitted my idea).

I do not see that the "concatenate indexing idea" is a duplicate of what I propose.

[jcarmody]

I wish everyone would get with the times.  "Green" is good, and OpenG already has this function.

[donkdonk]

@jcarmody,

I recently installed OpenG.

You're right, it's in there.

Probably worthwhile for NI to take a look there, I guess they're alreading doing so.

Nevertheless, for my idea there's no need for an extra node. The index array node is already there, just expand it's functionality.

[That Might Be G]

@donkdonk

The index array node is a resizable node that allows you to index into the array multiple times. It feels a little odd to overload that node to accept a boolean array that filters the input array. What would it mean to have the boolean array wired up and the node expanded to allow more than one set if indices?

I do agree, however, that replacing the case structure inside of a for loop with a single node would make the diagram code more readable and compact. My initial reaction, though, is that tst's example of a condition on the indexed tunnel is slightly more readable. I'm just not quite sure yet how we could make that condition discoverable by users. I definitely wouldn't want it to be turned on by default. It should be an option that you have to explicitly turn on. Otherwise you would have lots of cases where there would be unwired conditions on auto-indexing tunnels.

We'll keep this idea in mind the next time we are evaluating the array palette.

[donkdonk]

@That Might Be G,

>.. that filters the input array...

Actually, I would say that the (intelligent) filtering is done beforehand, in my example for all i: a(i)>2". The boolean array just (kind of) indexes the array.

>...that replacing the case structure inside of a for loop..

Not just the case structure, but the loop alltogether.

>..What.....the node expanded to allow more than one set if indices?...

Yes, that needs a little thinking, but nothing that cannot be solved. One solution is not to allow the node to expand if a boolean array is connected, an error message explaining if a wrong combination/wrong datatype is connected, ..

>We'll keep this idea in mind the next time we are evaluating the array palette.

That's good 😉 What's your role in all this?

Some further thinking brought me to the following addition(see diagram):

- The 1dim array as proposed

- Could be expanded to the 2dim array,

the index node still accepting a 1dim boolean array but applies this row wise.

[rgvdh@rdf]

I agree that this is not a duplicate of the "conditional auto indexing" but rather a different way of fulfilling the same need.

In my opinion, this way is cleaner.