The built-in LabVIEW comparison and array sort primitives are inadequate for many applications involving clusters. For example, the clusters may contain elements that
- Cannot accurately be compared using the default method, such as case-preserved but case-insensitive strings.
- Have a comparison sense (in a particular instance) that is opposite in sense to another member of the same cluster.
- Weight the ordering more heavily (in a particular instance) than another member, but whose location in the cluster is below the other member, and so have less effect on importance than the other member.
- Should not be considered at all in the comparison.
For example, consider the following cluster:
Now, suppose I want to sort an array of this cluster, but I am uninterested in the VendorCode or the Password, and I want the Server, Database, and User to be compared caselessly. The Sort 1-D Array primitive will not do this properly. The common pattern for overcoming this is something like the code below.
This does the job, but it is not particularly efficient for large arrays. I could code my own sort routine, but that's not the best use of my time, nor is it very efficient.
A similar argument can be made for simple comparison (lt, le, eq, etc.) between two clusters, although this is easily done with a sub-VI.
My proposal is to take an object-oriented approach and allow clusters to decide how they are to be compared. This would involve something like attaching a VI to a cluster (typedef). This would allow the default comparison of two of these clusters to be determined by the provider of the cluster, rather than the writer of the code that later needs to compare the clusters. I will leave it to LabVIEW designers how to associate the comparison code with the cluster, but giving a typedef a block diagram is one way that comes to mind.
Of course, different elements may need to be compared in different ways at different times. This leads to the thought that Sort 1-D Array ought to take an optional reference to a sorting VI to be used instead of whatever the default is. This idea was touched on in this thread but never thoroughly explored. The reference would have to be to a VI that conformed to some expected connector pane, with well-defined outputs, like this:
Strictly speaking, the x > y? output is not required here. Another possibility is
which simply outputs an integer whose sign determines the comparison results. Clusters that cannot be strictly ordered would somehow have to be restricted to equal and not equal.
The advantage to wiring a reference to such a VI into the Sort 1-D Array primitive is obvious. It is less obvious that there would be any utility to be gained from providing such an input to the lt, le, eq, etc. primitives, but consider that this would allow the specifics of the comparison to be specified at run-time much more easily than can presently be done.
