Does compare aggregates mode produce incorrect results?

[Guy04]

Has anyone encountered a problem with using compare aggregates mode with arrays. 

For example, if compare aggregates mode is selected in using the "In Range and Coerce.vi" with the inputs (upperLimit, lowerLimit, and x value)  being an array of integers, then compare aggregates doesnot return correct results.  I've also noticed this with the greater than and less than comparison vi's.

I've attached a sample which further illustrates the incorrect results.

[shoneill]

I see the same unusual behaviour in LV 8.20.

This may be a bug.

What version are you using?

It seems as if the output os "Or"ed instead of being "And"ed as it should be....... As soon as a single element in in range, the output is true.  I don't think this is expected, but maybe someone can enlighten us.

Shane.

Message Edited by shoneill on 04-04-2007 11:28 AM

[Guy04]

I'm using 8.2 but, I've also verified this with 8.0 as well.

[David L.]

This was reported to R&D (CAR #483H78HR) for further investigation. A possible workaround is to compare the elements one by one, and the AND the results. Thanks for the feedback!

[Roy_F]

---

@David L. wrote:
This was reported to R&D (CAR #483H78HR) for further investigation.

---

The actual CAR# is 483HDBHR.

[tst]

This also affects clusters - it looks like the function only examines the first element. Here's an example (7.0).

[tst]

At first I thought that maybe this only happens with the In Range & Coerce function, but it looks like this also affects the regular comparison functions. Here's another example.

[tst]

I talked to some people at NI and here's how I understand it:

Compare aggregates simply does not do what we think it does. It is NOT the same as comparing all elements and then ANDing the results. Instead, it compares the elements in the cluster in order. This is actually identical to ANDing the results when you do an equality comparison, but it's different if you do a less-than or greater-than comparison.

The LabVIEW help provides the example of a phone book, where "Smith, John" is greater than "Smith, Jane" and where "Smith, Jane" is also greater than "Doe, John" because Doe comes before Smith.

This helps to explain the results of my example:

In the first array element, the comparison fails because 10 is the first element in the cluster and it is less than 40.

In the second array element, 40 and 40 are equal, so the decision is moved to the next element (like having two "Smith"s, and since 40 is greater than 30, the comparison returns true.

So again, the order is important!

[tst]

Here's another example which explains the In Range & Coerce behavior -

The reason the comparison succeeds is that this is similar to asking "is GR found between EE and KK?". The answer is "yes" even though R is out of range. The object being compared is treated as a whole, where the order of the elements matters.

Message Edited by tst on 02-27-2008 10:04 AM

[Technico]

l still don't get the logic of this

I have the impression the Compare Aggregates only returns the first element of the Compare Elements.

--> When swapping 5 and 25 the compare Aggregates becomes false.