Finding the most common value in an array of enums

[Darin.K]

My crude estimates are that the lazy method I posted has O(10N) operations. 3 elements times 3 operations on N elements. The counting method has O(N) operations since there is one operation on all N elements. Sorting is O(Nlog2(N)) plus the 1D searching is O(N) because it does not take advantage of all the work you did sorting the array. For one million elements, log2(N) ~ 20 so there are roughly O(21N) operations. I guess the factor of ten is about right, and yes sorting is certainly the rate limiting step.

[JorgeF]

I am aware that I wrote "Very very large" array of enums, but in reality, most of the time the array size will be ~128. In such case scenario both methods would be fine to use.

I ran couple of benchmarks using an array of 128 enum values and the difference between both methods is not noticeable.

However, this enum mode.vi will be used in a sequence where other tasks are done before, and after this VI.

Therefore, if I want to avoid additional loading times if the array size were to be very very large, the brute force method would be my best bet.

Thanks a lot, Mark and Darin for your time.

[Mark_Yedinak]

---

@Darin.K wrote:
My crude estimates are that the lazy method I posted has O(10N) operations. 3 elements times 3 operations on N elements. The counting method has O(N) operations since there is one operation on all N elements. Sorting is O(Nlog2(N)) plus the 1D searching is O(N) because it does not take advantage of all the work you did sorting the array. For one million elements, log2(N) ~ 20 so there are roughly O(21N) operations. I guess the factor of ten is about right, and yes sorting is certainly the rate limiting step.

---

Nice analysis Darin. I guess the moral of the story is to consider all facets when deciding on what method to use. In the general case the brute force method is the better option. If you are guaranteed the data is already sorted then the search method would be a better option. This was an interesting thought experiment.

[Darin.K]

With C it is fairly easy to make accurate estimates of performance, LV can make things tricky. First of all, there are two sets of rules, one for primitives and one for G. Often you are better off doing something inefficient with a primitive than doing the right thing in G. Keep in mind that screwing up inplaceness is much worse than doing an O(N^2) operation instead of something O(N). With modern hardware the best solution is the one which is easiest to write and easiest to validate, time differences are usually negligible outside of tight loops even if the code is ready for the Rube thread.