LabVIEW
The quickest way to search a 2D array for matching
Solved!
Hello,
Please find the VI attached, full credit to altenbach from his previous reply on Re: How to match data in different array columns
I will be manipulating a 1000 row array with two columns for matching. I was just wondering if there was a quicker way to achieve this than the design below. I was just considering latency, especially with the fact that large batch tests will be run in the future.
I had an idea that a case structure could also be used to identify the user input, but wasn't quite sure if latency would have any impact.
Open to any ideas you may have.
Many Thanks & have a nice weekend!
Here's mine. I don't know how fast it is. I believe you can make a nice lookup table using variant attributes, but this is just easy...
@Gregory wrote:
I believe you can make a nice lookup table using variant attributes, but this is just easy...
Yes, this is clearly a prime case for a variant attribute table based LUT. Now you don't even need a case structure. 😄
You would place the parts on the left into a subVI and create a new variant whenever you want to load a new LUT from file. Note that a variant based LUT is very efficient.
(EDIT 04-18-2022: corrected attachment to remove extraneous \n default value in string control)
neunited wrote:I ran the simulation a few times comparing the original vs. your LUT and noticed a substantial improvement in the latency.
For large tables, the difference will be dramatic. "Search array" needs to inspect about half the elements on average before a match is found (best case 1, worst case N elements, if not found also N elements).
If you know that the array is sorted, you could substitute a binary search where it is sufficient to inspect only log2(N) elements before getting the result. (search array could add this option in the future, that's why I made this idea, but you could also roll your own of course). Imagine if you had a LUT with about 64k entries. Search needs to inspect between 1 and 64k entries (average about 32k, but every single element whenever the search fails) while a binary search on 64k elements only needs to look at 16 elements in the worst case, i.e. many orders of magnitude less.
Variant attributes use a highly efficient internal data structure (red black tree) that also performs in log2(N). I use it for example to cache the results of certain expensive calculations to avoid recalculations and it performs great (details).
@altenbach wrote:
@Gregory wrote:
I believe you can make a nice lookup table using variant attributes, but this is just easy...
Yes, this is clearly a prime case for a variant attribute table based LUT. Now you don't even need a case structure. 😄
You would place the parts on the left into a subVI and create a new variant whenever you want to load a new LUT from file. Note that a variant based LUT is very efficient.
Dude, that was awesome. 🙂
Hi sam,
see the attachment in message #5…
(When you want something else you should ask more specific!)
