Add "Element of Array?" function to Array palette

[Petru_Tarabuta]

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.

Thanks! 

[fefepeto_kb]

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]

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]

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]

@wiebe@CARYA, my point was, that this check is already done in the low level implementation. I had cases where shaving off a few instructions like this resulted in seconds within a 3 hour test run. And most of the time there is even more optimization that can be done, but if the low level primitives are already optimized, then we have less work to do.

On the other hand I agree that this can be done, but would still prefer this as an output of the primitives if this idea gets implemented.

[wiebe@CARYA]

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]

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]

> 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!).

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...