LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Petru_Tarabuta

Add "Element of Array?" function to Array palette

Status: New

One of the most common operations performed on arrays is to determine whether an element is found inside the array or not.

 

There should be a function that is dedicated to this fundamental operation. My workaround is to use the "Search 1D Array" function followed by a "Greater Or Equal To 0?" function, as seen below. While it only takes a few seconds to drop the geqz function using Quick Drop, it's still slightly frustrating that this is necessary.

 

The set and map data types rightly have been given the "Element of Set?" and "Look In Map" functions. An equivalent should be provided for arrays.

Element of Array - edited.png

 

Thanks! 

7 Comments
fefepeto_kb
Member

I think that adding a new primitive would make novice developers assume that it has the same performance as in the case of the collections. Which might not always be true and I'm specifically thinking about unsorted arrays.

I think, that it would be better to have another output for the Search 1D Array primitive, i.e.: found?.

I'm also sure that the equation check happens in the low level code, which would result in a little better performance as the current solution that we are implementing today, see the above screenshot, since there would not be an extra check needed.

PaulRB
NI Employee (retired)

I would expand this idea to include all primitives where -1 means not found. There are a lot of string primitives that behave similarly. More often than not, I use those primitives to find if a value is present and not to find the index of a value.

wiebe@CARYA
Knight of NI

Both Search Sorted 1D Array.vim and Search Unsorted 1D Array.vim would need a Boolean 'Found?' output variation as well.

 

But since those are malleable VIs, simply adding a Boolean 'Found?' output gives us this functionality. If it's not wired, the code is removed, so it won't cost anything.

 

That would be a fast way to get this done (although I'm not convinced it should).

fefepeto_kb
Member

@

wiebe@CARYA
Knight of NI

But if it's added to the primitives it will always be slower, while in the .vims it will be removed. For performance, you'd definitely want to use the ordered search if possible.

 

So the only option then is to make a new primitive (which is indeed what you suggested), but adding primitives might not be that easy.

fefepeto_kb
Member

I meant, that the LabVIEW team extends the current primitives with an output for Found?. I'm quite sure, that they do some sort of check to stop if the element is found, therefore they could easily output that value too, without too much extra overhead (copying the value). If we do it post mortem, by adding a less then zero, or a greater than or equal to zero it will always be slower then that.

Also, if it is not found by the last iteration of the array (last element's check) the value is also available. I would like to see this implemented on this very low level, likely in C code to maximize the performance.

wiebe@CARYA
Knight of NI

> If we do it post mortem, by adding a less then zero, or a greater than or equal to zero it will always be slower then that.

 

You might just be wrong about that. The G compiler got real good.

 

 

Spoiler

Doing the entire search in G (in a for loop) results in speeds that compete with the primitive (turn debugging off!).

 

Search.png

The location of the compare won't make a measurable difference, but if it was, the G compare and\or index return value will be compiled out. In the C code both are fixed. So G might just beat C...