"Reverse Lookup" using Variants?

[abvenk]

---

@Kevin_Price wrote:

To the OP:  a few fairly important questions

1. About how big a lookup table do you expect to need (what # of key-value pairs)?   If you're in the realm of 10's or 100's of pairs, variant attributes may not be a particular advantage over a conventional pair of arrays that are searched linearly.

2. How big can the unique arrays get?   The inefficiency of Flatten to String may not matter a lot if the arrays are pretty small.

3. Consider whether developer (you alone?) and maintainers of the code might benefit from a conceptually simpler approach even if it wastes some memory and microseconds.     To me, the simple pairs of arrays makes for the most conceptually simple and transparent of all these methods.   That's worth something for debugging and maintenance, and may be worth a little tradeoff against raw execution efficiency.

Note also that methods based on references such as DVR's or Queues have an additional failure mode not shared by data-based methods.  Between parallel code and dynamically launched vi's, there are ways for those references to become invalid while parts of your code still depend on the data they (used to) refer to.  Good programming practices can prevent and avoid this pitfall, but it *is* "out there".

-Kevin P

---

Hello Kevin P,

Thanks for the perspectives.

In fact, right now I just have a pair of arrays wired to a FOR loop doing the linear search. Each unique 1D array has a fixed size of 5 elements.

At this point I'm expecting not more than 10 pairs. But I thought I would "future-proof" the code by having a more elegant and efficient way of lookup.

As I've also done a lot of database design, I naturally think of this in terms of a "table query", and I thought there might be an easier way in LabVIEW. 

[Mark_Yedinak]

If the arrays are longer and you don't want to flatten them to a string, you could create a hash/crc for the array data and use that as name for the lookup. The longer the variant attribute name is, the more inefficient the looks are. A five element array in not terribly big so flattening that to a string would not be a problem. Now if your array has 100s of elements, then you would end up with a very long string for your attribute name. Creating a hash on the data would give you a fixed size name and one much smaller than the flattened array itself. A MD5 hash pretty much guarantees uniqueness for your array attribute names, provided that the arrays themselves are unique.

[wiebe@CARYA]

Note that the tree lookup of the variant attribute is slower per searched element then an array search. For 100 elements, worse case a linear search needs n*100 elements. A tree search needs m*log(100), IIRC. There is a break even point, n*100 might be faster then log(100)*m, if n<m, which it is. So for small arrays, a linear search might be faster.

It's only when there are lots of elements, that the tree search gets faster for sure.

Inserting into the tree could as well be faster, as a pointer is inserted into reserved space in the tree, instead of having to move parts of an array. However, since the search could be slower for small arrays, a linear array might still be faster overall.

So "making it future proof" by using variant only makes sense if the future means high nr. of elements. I'd stick with "optimize when and where needed".

And of course I'd wrap it in a class. That way, I can test and develop with the array version. When needed, I can switch the implementation in a blink of an eye. When the variant child does the same as the array child, everything will work as expected. You can even use the number of elements as a criterium determining which child to use...