Group Equal Values

[crossrulz]

Jeff, I'm disappointed in you.  You left a very obvious Rube (using autoindexing to say how many times to iterate the FOR loop but inside using Index Array).

Oh, and yours is still way too slow.  Slightly faster than Greg's original, but mine is still the speed demon.

Now that I have said that, Altenbach will chime in and put up something that will destroy my benchmark.

[crossrulz]

Ok, so after dinner I decided to go back to this and play.  I am pretty sure this is what Tst was trying to say.  I am using the original array in order to build up my grouped arrays.  I then keep track of how many elements are valid in the grouped array.  Use Replace Array Subset to add to the group and then Array Subset at the end to only have the valid elements.  I learned this trick while trying to help with OpenG last year.

I also found some issues with the way I was doing benchmarks.  So Greg's original was not as bad as I first thought.  But Jeff's was worse.  But in the end, here is what I ended up with.

EDIT:  BTW, you might want to give this thread oven in LAVA a good read:OpenG Filter Array Revised

[JÞB]

---

@crossrulz wrote:

Jeff, I'm disappointed in you.  You left a very obvious Rube (using autoindexing to say how many times to iterate the FOR loop but inside using Index Array).

Oh, and yours is still way too slow.  Slightly faster than Greg's original, but mine is still the speed demon.

Now that I have said that, Altenbach will chime in and put up something that will destroy my benchmark.

---

what version did you benchmark in 2012 or 2013?  and you are a bit too quick to declare RG my brother  (the current optomizer saves me there). What is that comparision function driving the case selector doing in the inner loop?  You can do better!  an array sort preloop would allow a conditional exit on the outer loop and parrallel operation on the inner loop (But that would have produced an array in different element order).  all those case structures just bug me and make the code less readable than some newer tunnel features.

I didn't have 2013 at the work PC. 

[tst]

Actually, what I suggested was something like this:

The top array holds the values we already found and the bottom array holds the count for each value.

What's nice about this is that it's very simple and that it has no while loops and no dynamic building. It iterates over each element exactly once. What's not as nice about it is that it creates two additional buffers of size N, which might be an issue if N is large.

As for the unique identifier of the class to use for the variant attribute name or the lookup, I would say that highly depends on the class, but let's assume your equals VI has a compound AND at the end which says "yes, these two objects are the same". You could probably take the things you're comparing in the objects and concatenate their values into a single string value, which would cause all the objects that satisfy specific conditions to generate the same value.

[GregFreeman]

Ooo, this is fun! I'm getting a CLA Summit vibe. 

Anyways, the arrays won't be that big and this VI, although on RT, is part of a configuration state so there is nothing about it that needs to operate overly fast. I was just curious, for my own knowledge, of other solutions. I appreciate all the input; I'll try to make a compromise between the least obfuscated and the most perfomant. 

[tst]

I should probably point out that mine has a bug - it will fail to correctly handle values which are 0, because they're already in the initialized array. You can handle this by using an invalid value or using Array Subset before searching the array. The Array Subset option should probably also improve performance because if a value is not in the array, you have to iterate through fewer elements (or you could use variant attributes for just that part of the search).

[altenbach]

Interesting problem. What will actually consume this output? Do you have control over it?

It seems you are retaining a lot of redundant information, because all elements in the arrays are identical. You could keep the same information compressed to a fixed size by having a 2D array output where the first column is the count and the second element is the value, one row for each value, for example.

Do the values need to be in some specific order (sorted numerically, by first occurence, sorted by count, etc.)).

[GregFreeman]

---

@altenbach wrote:

Interesting problem. What will actually consume this output? Do you have control over it?

It seems you are retaining a lot of redundant information, because all elements in the arrays are identical. You could keep the same information compressed to a fixed size by having a 2D array output where the first column is the count and the second element is the value, one row for each value, for example.

Do the values need to be in some specific order (sorted numerically, by first occurence, sorted by count, etc.)).

---

Altenbach -

Basically, in my actual application I have channel configuration information that I am using to group channels into DAQmx Tasks. If certain configuration information between channels is different, they have to be put in different tasks. If that certain information is the same, they are grouped together in the same task. Yes, this information I am using to determine whether they can be grouped together is redundant once things are grouped, however there is information on a per channel basis that is not redundant (i.e. channel specific info) but that doesn't validate whether or not the channels can be grouped into the same task.

To parphrase with an example, think: Array of clusters, where each cluster holds 5 elements. Group any clusters together that have the first 3 elements the same, but still retain all data because elements 4 and 5 are different.

Does this help clarify? Maybe I shouldn't have posted the diluted example of using numerics; I didn't realize how drastically different solutions can be based on what I'm grouping!