Equals, Boolean To 0,1, Add Array Elements. No loop required. Though, it sounds like something that would be a prime candidate for a Malleable VI (*.vim).
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Performance-wise, crossrulz, that would be the slow way to do it. Equals, Increment, shift register.
But I agree, it sounds like a reasonable VIM candidate. There's no reason to make it a built-in primitive of G: I would expect the VI will compile down to be as efficient as we could possibly make it internally.
Building the array of output indexes is slow performance when you don't need it, so I'd suggest two separate VIMs, "Count Matching Elements" and "Find Matching Elements".
The simple versions are shown below. The ones I'd suggest shipping would be overloaded so that you could pass an element OR you could pass an equals operation parameter (VI refnum or LV class, defined exactly like the new VIMs in LV 2019 found in "vi.lib\Array"... if you haven't seen them, please go take a look).
(If you want to use these snippets, left click on the image, see the floater window appear, and click the Download button () under the image. Save it to disk and then you can drop it on your block diagram as actual code.)
>Building the array of output indexes is slow performance when you don't need it, so I'd suggest two separate VIMs, "Count Matching Elements" and "Find Matching Elements".
So there's no change the unused parts will be removed as 'dead code'? I'm not sure how sophisticated that process is. Sure would be interesting to know.
Search 1D Array in a loop with previous index +1 in the shift register used to be way faster then a compare in a loop. Did we all just imagine that or did things change?
> Search 1D Array in a loop with previous index +1 in the shift register
> used to be way faster then a compare in a loop.
Spent a couple hours doing benchmarks this morning in 2019 (probably not a good use of my time, but I didn't want to just ignore you). There may be an advantage around arrays of 500,000 elements, but it was close to noise... the signal was at best .002 seconds advantage over 500,000 elements. Definitely not "way faster", and not worth the loss of readability, in my opinion, if it is there.
@AQ: Thanks for that. I'll accept that as the new truth. Quite spectacular actually.
I still wander if this was always the case. This preference for the Search 1D Array might date all the way back to a benchmark in LV4, ~1998... It could be completely unfounded, but IIRC there has been major optimizations. For instance to autoindexing, but compiling in general (since LLVM?). No need to test that, but does this make any sense?
It does make sense. Also, it would depend where the benchmarks came from. I don't trust most benchmarks. I've had way too many people say, "Oh, that's bad performance," only to find they weren't benchmarking what they thought they were benchmarking, for a wide variety of reasons. There's no such thing as a "quick benchmark". 🙂
Not wiring Indices (wiring Count) makes execution as fast as not programming it.
Not wiring Count (wiring Indices) doesn't make a difference.
Not wiring any output removes the entire thing.
I think the counting is noise compared to the rest...
It's ain't easy. Haven't even tested different array sizes, different data types, different CPUs, etc. Not sure if the compare in or out of the loop makes a difference... I should leave the benchmarking to more patient people.
Sorry, I guess I don't understand the idea. The number of matches is probably less important than the location of these matches and it seems most have silently assumed that the OP wants an array of indices if there are multiple matches (the picture shows a scalar index output, though).
If we only want a single index (i.e. the first match after start index), getting the count seems pointless and inefficient. If we are getting all matching indices, an "array size" would do the trick to get the count.
I thought openg already has a VI that returns all matching indices.
