LabVIEW
Find All Matching Elements in a 2D array
Solved!
Ok, After playing with it to try and simplify the code, I found a few edge cases.
Here is what I have currently:
Please let me know what you think
@ATE-EGNE wrote:
Please let me know what you think
So your changes mostly deal with new input specifications by allowing e.g. empty strings and empty rows. 😄
The first innermost conditional tunnel is pointless, because the "array to cluster" again pads it to 2 elements anyway before throwing the row away in the outer loop. Instead of the inner conditional tunnel, you could just auto-index the boolean followed by "AND array elements" to trigger the outer conditional tunnel accordingly. I am not sure if all that data massaging is really necessary, because the variant will reject empty strings (as names) anyway, probably with little speed penalty.
In terms of optimization, I think you could get rid of most prep work and initial sorting by making the code near the first case structure a bit more intelligent, depending on if both elements are unseen or only one is. Also, if an element already exists, we don't need to write it back to the variant, same for empty strings.
Also, the parts after the variant processing could probably be optimized, again probably at the cost of more code.
I intentionally kept everything simple and readable. 😄
@altenbach The first innermost conditional tunnel is pointless, because the "array to cluster" again pads it to 2 elements anyway before throwing the row away in the outer loop. Instead of the inner conditional tunnel, you could just auto-index the boolean followed by "AND array elements" to trigger the outer conditional tunnel accordingly. I am not sure if all that data massaging is really necessary, because the variant will reject empty strings (as names) anyway, probably with little speed penalty.
I found that with an empty row or a row of {'','\s'} would produce a blank row in the output column
@altenbach In terms of optimization, I think you could get rid of most prep work and initial sorting by making the code near the first case structure a bit more intelligent, depending on if both elements are unseen or only one is. Also, if an element already exists, we don't need to write it back to the variant, same for empty strings.
Also, the parts after the variant processing could probably be optimized, again probably at the cost of more code.
Ok, I'll go ahead and try and make some improvements there. Thanks a ton for getting me started!
I intentionally kept everything simple and readable. 😄
Thanks for that! This type of sorting is new to me so I'll take a crack at improving it further.
Also, you said that you don't use the open G toolkit. Is there any reason why? I've found some of the functions (like trim whitespace) are significantly more efficient than the native LabVIEW equivalents.
@ATE-EGNE wrote:
@altenbachAlso, you said that you don't use the open G toolkit. Is there any reason why? I've found some of the functions (like trim whitespace) are significantly more efficient than the native LabVIEW equivalents.
It's just a personal choice. For most of what I do, stock LabVIEW gives me all I need and I know enough tricks to do everything with them. Having to search through the OpenG palettes to find something that does it too, then verifying that it correctly works in my special use case takes too long. Also, I spent way too much time installing LabVIEW (several machines, all versions, betas, etc.) that I simply don't want to waste any time installing extra stuff and customizing forever. That said, the OpenG libraries are great, I just don't bother. I want to be able to sit down at any computer that has LabVIEW without complaining that I cannot do something because some libraries are missing. 😄
Yes, that banana slicer works fast, does a great job, and is fully debugged (unless the banana curves the other way! :D), But in a pinch, a regular knife works just fine and I don't need to rummage through all my drawers (palettes) to find that special tool.
