LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

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.
0 Kudos
Message 11 of 19
(1,459 Views)
Ok, thats a good example.


Message Edited by OnlyOne on 12-04-2007 09:22 AM
0 Kudos
Message 12 of 19
(1,453 Views)

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. Smiley Mad

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

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 13 of 19
(1,445 Views)

smercurio made it clear... thanks.

allthough i don't like it....

0 Kudos
Message 14 of 19
(1,441 Views)

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.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 15 of 19
(1,415 Views)
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).
0 Kudos
Message 16 of 19
(1,414 Views)
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.
0 Kudos
Message 17 of 19
(1,381 Views)

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

Comparison Mode.PNG

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".

0 Kudos
Message 18 of 19
(878 Views)

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.

 


___________________
Try to take over the world!
0 Kudos
Message 19 of 19
(857 Views)