New Compound Arithmetic Function - "Equal"

[McTOM]

Hi,

My idea is as simple as the title states - an additional Compound Arithmetic function that works like "Equal?", but with multiple inputs and single boolean output.

I believe it is fairly easy to implement such functionality, and I can see no other single block that could compare multiple values, and offer easy expansion as well.

The easiest way to build similarly working VI (that comes to my mind right now) below.

[PhillipBrooks]

I'm not sure of your experience so far with LabVIEW, from your profile it appears to be ~ 6 months.

There is a mode for several of the comparison functions called "Compare Aggregates"

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/comparison_funcs/

You can compare two arrays (with certain limitations, see the link above) and the result is a single Boolean output.

[crossrulz]

I would just index the first element of your array, compare with Equal to the original array (don't want to reallocate array memory), and then use AND Array Elements.  Obviously, there are many ways to do this.  But I like you idea.  It would make things much cleaner.

[McTOM]

PhillipBrooks, my code looks the way it is just because it is fully scalable simply by altering the "Build Array" block size. Your code, as far as I am concerned, expects an array with even number of elements, and half of its size is an another argument one needs to provide.

crossrulz, I like your idea too. Until my suggestion is included in next LabVIEW, I think I'll use your idea for my purposes. Hopefully, not forever. 😉

[altenbach]

You could simply do an Array min&max and then check if min and max are equal.

I am not sure we need your suggestion, but if implemented, we would also need a "not equal" version for symmetry. We would also need to define what should happen if one, some, or all elements are NaN, for example.

[X.]

Notwithstanding the fact that looking for strict equality between doubles (your example) is a risky business...

[AristosQueue (NI)]

I like the idea. In the meantime, here are the two ways that I would implement a feature like this today:

[altenbach]

AQ, my suggested min-max version seems to be faster in 80% of cases (using 10M DBL elements) and has the advantage that it's speed does not depend on where the differeing element is (always ~13ms). You loop version is the same speed if the differing element occurs 20% into the array, slightly faster if it occurs earlier (~8ms if the first and last elements already differ), but more than 2x times slower if the differing element occurs after 20%. (32ms if all elements need to be compared).

The real killer in your code is the "delete from array". If you use your code but use "index array" instead and make one redundant comparison, things speed up dramatically, especially for early differences (~two ordes of magnitude!)

min&max: 13ms independent on position of first differing element.

Yours: 9ms..32ms, depending on position of first differing element

Using index array instead of delete from array: 0.06ms(!!)..20ms, depending on position of first differing element

[AristosQueue (NI)]

> The real killer...

Altenbach: Weird. I would have thought that the Delete From Array would have used a subarray and avoided any data copies.

[Darin.K]

> Weird. I would have thought that the Delete From Array would have used a subarray and avoided any data copies.

That primitive is a real dog, except I like dogs.  You once raised my hopes with CAR #377978, but that sucker stays on the shelf for at least two more years (right next to Insert Into Array).

[altenbach]

> Weird. I would have thought that the Delete From Array would have used a subarray and avoided any data copies.

Even weirder, there are no buffer allocation dots anywhere near it. So what slows it down?