From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
jdoyle

Provide more control over comparison of clusters

Status: Declined

Any idea that has received less than 8 kudos within 8 years after posting will be automatically declined.

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:

db-cluster.PNG

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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.

sort-pattern.PNG

 

 

 

 

 

 

 

 

 

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:

compare 1.PNG

 

Strictly speaking, the x > y? output is not required here.  Another possibility is

compare 2.PNG

 

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.

3 Comments
Intaris
Proven Zealot

To quote: "ttaching a VI to a cluster (typedef)"......

 

That's essentially LVOOP.  It exists already and will probably manage just what you're looking for, but with encapsulation of the data.

jdoyle
Member
Ok, so if I have an array of objects and I want to sort the array using a compare method defined as a class member, how do I do that?
Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 8 kudos within 8 years after posting will be automatically declined.