Compare two arrays (greater-equal) has wrong result. Bug?

[smercurio_fc]

It's not the first element, though it appears that way. The decision is made on the first unequal pair, as previously mentioned. Open the example "Greater - Various Uses" that comes with LabVIEW. It shows various examples, including a comparison of arrays using aggregate mode. As the example describes in a block diagram comment:

When comparing the aggregates of an array, the Greater? function compares
each element individually starting at index 0 until it finds the first set of
elements that are not equal. The comparison of these two elements yields
the result. Notice how the comparison of the first y value(s) in this graph
determines the value of the boolean indicator.

Bottom line: for what is being done in the original example, aggregate compare mode should not be used, though the poster has already figured that out.

[OnlyOne]

Ok, thats a good example.

Message Edited by OnlyOne on 12-04-2007 09:22 AM

[Ben]

I'll try to return to this Q latter today.

There is an explanation for this behaviour that simply will not come to mind at the moment.

For the time being, I concider this mor a bug in my memory than in LV.

Ben

[Pnt]

smercurio made it clear... thanks.

allthough i don't like it....

[Kevin_Price]

FWIW, it strikes me as puzzling and arbitrary that "the first unequal elements" get to dominate the aggregate result.  I think a case could be made for an implied logical-OR of the element results and an even better case could be made for an implied logical-AND.  But to make the aggregate result potentially depend on the SEQUENCE of the elements?!?   Weird...

(I know "bug" is a touchy word.  If the node behaves as designed/documented, it won't be considered a "bug."  But what a weird design, IMHO.)

-Kevin P.

[JDave]

I had a similar concern once with the "In Range and Coerce" function that has the same behavior.  Gave me such fits...

It was explained to me that it behaves like a phone book.  If you check whether {C,M} is in the range of {A,T} and {D,W}, you will find that it is.  Even though M is not within the range of T..W, the first element is within range.  And in a phone book "Michael Call" is within the range of "Tina Adams" and "Walter Dean".  That example helped it make more sense in my head.

The Compare Aggregates does not aggregate the element-wise comparisons, rather it compares the entire aggregate as a whole. 

You get a choice with the Compare Elements option.  You perform your own aggregation by ORing the results (is any element greater than) or ANDing the results (are all elements greater than).

[DFGray]

Getting back to your original problem, if you have the full or pro version of LabVIEW, Limit Testing.vi will probably do what you want.

[User002]

I'd like to get community input on submitting this as a bug. The current behavior is not only undocumented:

It is also wholly at odds with the intuition of everyone I've presented to. Please see the attached .vi, whose behavior I find immensely confusing.

I get that the function is comparing aggregates rather than aggregating comparisons, and I get that aggregates of an array might be compared using the "phone book" method, but unless the documentation is updated to reflect current behavior this will be a recurring problem. Addition of an "aggregate comparisons" mode would help clarify. Maybe an "OR all comparisons" and an "AND all comparisons".

[tst]

If you click the second link in that help article, you should find (among many other things) the following paragraph:

---

Compare Aggregates Mode

In Compare Aggregates mode, comparison functions return a single Boolean result after comparing the elements in an array. Comparison functions compare elements sequentially until a decision can be made, much like the alphabetical ordering of English words, where letters of each word are compared until they are not equal. Therefore, the function performs the following steps to determine the result of the comparison:

• The function compares corresponding elements in each input array, starting at the beginning of the array.
• If the corresponding elements are not equal, the function stops—it returns the result of this comparison.
• If the corresponding elements are equal, the Comparison function processes the next pair of values, until it finds an inequality or reaches the end of one of the input arrays.
• If all values in the input arrays are equal but one array has extra elements at the end, the longer array is considered greater than the shorter one. For example, a Comparison function considers the array [1,2,3,2] to be greater than the array [1,2,3].

---

There's a similar paragraph for clusters. I don't know if that's the best place to put it (maybe there should be at least a note in your screenshot), but it is in the documentation.

As for which is better, I have no particular opinion. My intuition was also that compare aggregates simply means "AND everything" (which it does, if you're equating) and I was confused when I first ran into an inequality which didn't behave that way, but I use this rarely enough that I don't have a strong opinion.