Compare elements in an array

[GRMAN]

Hello all, I am new to Labview. I would like to compare two arrays by element and get back the location of the elements that are not equal. I am sure this isnt real hard to do, but like i said i am new to this. Any help is Greatly appreciated.

[chrisger]

hello

compare the two arrays with the comparison node, right click and select comparison mode->elements. then the node returns a boolean array, each element ist the result of the comparison of the corresponding elements of the two input arrays.
then run a for-loop over the boolean array, if the value is FALSE contenate the index of the loop to an integer array (use a shift register initialized with an empty integer array). the shift register then retuns an integer array with all indices of elements which are not equal.

have fun
chris

[joeycao]

"compare the two arrays with the comparison node, right click and select comparison mode->elements. then the node returns a boolean array, each element ist the result of the comparison of the corresponding elements of the two input arrays.
then run a for-loop over the boolean array, if the value is FALSE contenate the index of the loop to an integer array (use a shift register initialized with an empty integer array). the shift register then retuns an integer array with all indices of elements which are not equal."

IS there a slicker way of doing this without using a loop or shift register or sort?

[JQ]

i do not think you can do this without a loop... the requirement is to locate the position of the differnt element... i've attached an example to make the description of using loop and shif register mentioned earlier clearer...

[altenbach]

Here is one simple solution. I would do the comparison inside the loop to avoid allocation of the boolean array. (there is also no need for any local variables as in the example given above).

This is perfectly good code for small to medium array sizes. If the arrays are very big and have a huge number of differences, you might want to allocate a full size array in the shift register, then replace elements with indices as you go. After the loop, trim the output to the final size. This avoid growing an array in a loop with the associated memory allocation overhead.

Message Edited by altenbach on 12-28-2006 11:37 PM

[tst]

Here's another version, probably more efficient on larger arrays than Alten's, because even though it has to allocate an extra n*2 bytes array (the conversion to 0,1 which produces an I16 array), it avoids having to allocate the n*4 bytes, avoids running over the entire array (fewer iterations) and avoids having to do the cutting.

I didn't bench them, though.

[altenbach]

---

@tst wrote:
I didn't bench them, though.

---

I suspect that the result is quite input dependent and it would be worth fine-tuning on typical data. Last night I actually made two more quick version as a little exercise (see picture).

(A) is probably very efficient for very large input arrays with very few differences.
(B) is probably good for very large input arrays that are mostly different.

(Notice that my example uses integers. As we all know, comparing floating point with "=" or "!=" can lead to somewhat unexpected result, depending on where the data has been. :))

tst, while "search array" is very efficient, it still needs to "run over the entire array" one way or the other, just internally to its function in this case. 😉

JQ, your code is incorrect because it can lose output data in the worst case scenario. Since there is no data dependency between where you initialize the output array with an empty array (lower left of code) and where you write to a local variable of it (inside the loop), it could happen that the array is cleared after some values have already been written to it. Code does not necessarily execute left to right and your code does not define what should happen first. Such race conditions are an inherent side effect of careless use of local variables. Whenever local variables are used, the code needs to be carefully reviewed fo such things. 

Message Edited by altenbach on 12-29-2006 10:00 AM

[tst]

---

@altenbach wrote:

I suspect that the result is quite input dependent and it would be worth fine-tuning on typical data.

---

I would definitely agree to that - all these are highly dependant on the typical input data and on things like potential compiler optimizations and such, and where such efficiency is needed, some real testing needs to be done. I agree that your first implementation is probably more efficient and I know better than to try to fight you on optimization issues unless I have the time to do all the necessary testing . In any case, I doubt the original poster will need all this.

---

(Notice that my example uses integers. As we all know, comparing floating point with "=" or "!=" can lead to somewhat unexpected result, depending on where the data has been. :))

---

Valid point. It was, of course, just a very quick example.

---

tst, while "search array" is very efficient, it still needs to "run over the entire array" one way or the other, just internally to its function in this case. ;)

---

Well, you know what I meant.

[altenbach]

Oh yes, the problem is certainly solved!

I agree with everything you said. In 99% of all cases the simplest code is appropriate because performance is not an issue. Nobody cares if it takes 0.1 or 10 microseconds. 😉 If performance is an issue, I never trust my instincts until I see actual benchmarks.

---

@tst wrote:
... In any case, I doubt the original poster will need all this...

---

Still, there are many readers with varying LabVIEW experiences that come here for entertainmentideas, and a spirited, somewhat more global discussion can break the monotony of (problem->solution ... problem-->solution ... bug--> workaround ... problem-> solution....). A few illustrated side-trips here and there can stimulate the thought process, give ideas how to do things differently, and point out how the diffferences potentially affect memory use vs. speed vs. code readability, etc.

Have you noticed that a large percentage of code posted here recently uses insert into array instead of build array to append a single element to an existing array? For me this complicates code readability because it is not universally obvious why "insert into array" would even act like that when the index is not wired (without looking at the help, some might guess it gets inserted at the beginning). With build array, there are no unwired inputs and it is immediately obvious that the element is added at the end of the array, just by looking at the icon.

Hopefully we got some people interested enough to duplicate our various versions, run some benchmarks, and try to come up with competing code that's even better. 🙂

LabVIEW is fun!

---

@tst wrote:
Well, you know what I meant.

---

😄

Message Edited by altenbach on 12-30-2006 10:35 AM

[tst]

---

@altenbach wrote:

...it is not universally obvious why "insert into array" would even act like that when the index is not wired (without looking at the help, some might guess it gets inserted at the beginning).

---

Here's a nice one for you - in at least one version of the PDA module, the Insert into Array primitive did insert the element at the beginning of the array, but only after your code was converted to C and run on the PDA. That did for some fun debugging (and don't ask me why I used it instead of Build Array. I really don't remember  ).

---

Hopefully we got some people interested enough to duplicate our various versions, run some benchmarks, and try to come up with competing code that's even better. :)

---

Yeah, right.