array comparator

[JASC12]

hello.
I am having problems comparing two csv files of different size. For example:
file1                  file2
comp1,true       comp1,true
comp2,true       comp3,false
comp3,true       comp5,false
comp4,true
comp5,true
.
.
.

At the end I want to display the differences of the components in an array.
differences
comp3,false

[Bob_Schor]

Your task is poorly defined.  You present two arrays, one with 5 elements, one with 3 elements.  Right there are two differences, namely Array 1 has two elements more than Array 2.  Of the three elements that are common, there are two that differ, yet you list only one.

You know, I presume, we are not going to do your homework for you.  When you reply, be sure to attach your LabVIEW code (preferably as a .VI file, maybe with a picture of the Block Diagram, but definitely "runnable" code (meaning the .VI file).  Also, try to specify the requirements better (feel free to attach the actual assignment ...).

Bob Schor

[pauldavey]

You might want to read up on maps.

[altenbach]

---

@JASC12 wrote:

hello.
I am having problems comparing two csv files of different size. For example:

---

A CSV file is just a long string of characters where some have special meaning ( comma to separate rows and linefeeds to separate rows) while the rest are typically from the subset of printable characters.

A "difference" can be defined in many ways. It almost seems like you want to look at the tag (comp#) before the comma and then see if the value after the comma differs (true vs. false).

There are quite a few possible scenario:

1. A tag exists in both files and the value is the same
2. A tag exists in both files and the values differ
3. A tag only exists in file #1
4. A tag only exists in file #2
5. A tag exists more than once in a file and the value is always the same
6. A tag exists more than once in a file and the value differs from entry to entry
7. etc.

In your example, I cannot really tell what the rules are that "comp3,false" is the solution. Why not "comp3.true"? Why not also "comp5..."?

Are there other assumptions? E.g. Is file #2 always a subset of file #1?

[JASC12]

Sorry for the ambiguity.
the first csv file I have I use it as a database, all the components that are different from false I segregate them and save them in a variable, then I look for those components in another file and verify that they are the same.

[altenbach]

You have blatant race conditions due to the glaring overuse of local variables. You have three independent code fragments that all run at the same time and all these local variables get read way before their respective indicators have been updated. (Most likely they contain stale data from an earlier run!).

Also remember that if you autoindex with two arrays on a FOR loop, the shorter array wins. Can we assume that the entries are always sorted? In your first example, true/false were lowercase. Why do you compare with uppercase TRUE?

Step zero: Do some basic tutorials about dataflow!

Step one: eliminate all local variables and use plain wires! This will ensure proper execution order and eliminate race conditions. Local variables are not "storage"!) (In your image, but not in the attached VI(!), you "fixed" the race conditions by using sequence structures. Two wrongs don't make a right! There is also no need to spin the loop as fast as the computer allows!)

Step two: use path datatypes instead of strings (paths as string are only needed when interacting with external code. The path datatype is OS independent and has certain sanity checks).

Step three: For better help, attach two simple example files and tell us what you expect as result.

[altenbach · Accepted solution]

See if something like this can give you some ideas. I am sure it needs to be polished.

(Note that scanning a string as boolean is useful because it is case insensitive and understand several forms of the terms. e.g. FALSE, False, false, f, F, N, No, etc. for "false", or TRUE, True, true, t, T, Y, Yes, etc. for "true".)

[JASC12]

Thanks, I am very sorry for the inconvenience, I am new to labview, with that example you provided me I got some ideas with the "scan from string function".
I consider this issue solved.

Thanks again for your help.

[altenbach]

As I hinted in the diagram comments, there are several optimizations possible that would be important if the database is large.

If we can assume that the database is sorted, the search can start after the previously found entry instead of the beginning for a moderate speed gain.

Even better, you can place the entries in a SET for much faster testing to see if they exist or not.