Search 1D array with all the indices of the matched elements

[Zekasa]

Hi,

 the "Search 1D array" function returns only the index of the fist item found. However some times, it is needed to get all the indices of the elements that match the element the we are searching for. I think it will be nice if this vi returns all the indices that match the element we are looking for.

   

to become like this

[AristosQueue (NI)]

The basic primitive should not do this since that would be inefficient for those times when you only need the first instance. Having a separate search function or a configuration option on this primitve is a reasonable request, however.

In the meantime, this node does give you a way to find all the matches -- the "start index" input can be used in a loop, and each time you call it, add 1 to the previous iteration result until you get a negative number. Because it is so common to need to do operations on each result as it happens, this is often much more efficient code than code that returns all the indicies in one list. Even if we offered the version that returned all the indicies in an array, you would often still want to use this node for performance.

[WG-]

The OpenG libraries function "Search Array", http://wiki.openg.org/Search_Array, provides the functionality you need. You can download OpenG with the VI package manager available at http://jki.net/vipm.

[Zekasa]

Hi Aristos,

thank you for your comment.

Your explanation is nice, and I know that you can play around using this function to get the same result of my suggestion. However there are some cases in which it will be more efficient if you get all the indices from a single run for the function (without using a loop). For example, some times you need to know the total number of elements that matches the element your are looking for, such as you have an array of Boolean and you want to know the number of "True" or "False" elements in this array.

Thanks again.

[AristosQueue (NI)]

> For example, some times you need to know the total number of elements that matches the element your are looking for,

Actually, that is a case where using the existing primitive would be more efficient. The existing primitive would allow you to get the count without ever allocating the array of indicies. You say "without using a loop" -- that's just more compact on the diagram. Under the hood of LabVIEW, obviously there would still be a loop. A For Loop on the diagram and a For Loop in the generated code of a primitive are exactly the same cost performance wise.

Packing more funcitonality into a node does not mean that the functionality becomes more efficient. It just limits the usefulness of that node in situations where you don't want it doing all that work.

[Darin.K]

Why not take your argument to its logical conclusion and bag the search entirely for an element by element comparison?

[SteenSchmidt]

Darin, I think Stephen is right - I'd probably never use the "Get all indices" function either. But the complexity bar has to sit somewhere, and I'm definetely more comfortable with it being where it is than ditching the search array function altogether 😉

Or else we'll soon be back coding in opcode only. I'll reserve that recollection for when I start programming quantum computers someday... Hey, anobody else looking forward to the "LabVIEW for Q" version?

Cheers,

Steen

[Darin.K]

One advantage of writing out the code longhand is that you would realize what a Rube contraption that example was. A simple For Loop, Select, and increment gets the job done, add Equals for non-booleans. When conditional auto-indexing is real, getting the indices will be a snap. That to me is a more viable alternative than looping and searching. At any rate there is no way I support changing the behavior of an existing primitive or adding a second one when the first is unnecessary IMO.

[AristosQueue (NI)]

> Why not take your argument to its logical conclusion and bag the search entirely for an element by element comparison?

Because an element-by-element comparison is *exactly equal* to the primitive. There's no point to ditch in favor.

[Darin.K]

Following your argument that loops in a primitive equal loops in G, your posted example has a loop in a loop which is gratuitous for counting. You make one of my favorite points (operations in primitives are not free) and then follow with one of my peeve constructs assuming a 1d search saves loop iterations. There was a day when primitives were much faster, not so much these days.

[AristosQueue (NI)]

Darin, my point was to show Zekasa how the prim would work in his counting example, not to say that's how I would code it. I didn't intend to assert that it saves operations over a loop with a plain Equals prim in it, but rather to show that I wouldn't get the array of indicies and then take the array size.