Search 1D Array Until Done - a New array function.

[Broken_Arrow]

This is a follow through for Zekasa's Idea posted here. It was suggested that the function be a separate one, which I agree. I would like to see this in LabVIEW's basic package, without adding things onto the install, or coding it.

[egraham]

Well if you coded it yourself wouldn't that first time be the only time you have to do it?

I was looking at the OpenG version of this and it does exactly what Darin and Aristos were discussing in the post you linked to. There is a search 1D array function inside of a loop - a loop inside of a loop. For the sake of performance it might be interesting to put that example up against your own version that didn't use the built in search 1D array function. If you do, let me know what the results are!

Eric

[PhillipBrooks]

This might be nice for integer values, but I would be concerned that a search for floating point values may not return the expected results for someone unfamiliar with the subtleties of comparing floating-point numbers.

[AristosQueue (NI)]

Didn't we establish in the other idea thread that this primitive would be inefficient for just about all real use cases because it actually constructs the array of indicies? I'm pretty sure that was the consensus.  As a separate primitive, it avoids interference with the main prim, but it would still be in the palette, as if it were a good idea.

Maybe the ease of programming balances the inefficiency?

[Darin.K]

I do not understand your use of inefficiency here. If you want all of the indices then it will cost you O(N) operations. It may be slow for large N, but that does not mean it is not efficient. If you turn it into an O(N^2) operation that would be inefficient. As long as you avoid memory thrashing while building the array, I consider it to be efficient. Now finding all of the indices simply to count them or to find the first one would be inefficient. I am not in favor of this new primitive since I already feel its cousin is already wasting prime palette real estate, but if people want it I think it can be done as efficiently as possible without much trouble. I will add that if/when conditional autoindexing becomes a reality I will have essentially no use for either function.

[AristosQueue (NI)]

> If you want all of the indices then it will cost you O(N) operations.

The problem is that you pretty much never want all the indicies. What you want to do is an operation on each index along the way... building the array of indicies is itself the inefficiency. Just iterate over the array doing the find startng from +1 of the last one found is a lot more efficient and you never do any memory allocation to build the array.

[Petru_Tarabuta]

+1. "What you want to do is an operation on each index along the way" - Fully agree that this is the best approach when it is possible/suitable. But I disagree with "The problem is that you pretty much never want all the indicies." - in my experience this is not so uncommon.

The Search 1D Array-VIM.vim (part of the Hooovahh Array VIMs VIPM package) implements what this idea asks for. But it would be nice for this behaviour to be available natively.