From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Best/Most Efficient Way to Determine What Changed in Array of Cluster
I have, on my Front Panel, an array of Cluster. The Cluster containing a bunch of stuff. I'm essentially designing a simple user friendly sequencer. Each time the user modifies something on the Array, I trigger an event that the sequence changed and I want to do a "scrub" to make sure whatever they've done is not breaking a bunch of rules and etc...
Here's what I've found to be effective for small arrays (sequences). But if the array starts to get large, I feel like this would bog down a bit due to all the array manipulation. Anyone else got any ideas on how to dig through it and confirm what changed? Right now, I'm just comparing Old to New to find the item/element that changed. The event structure just produces New/Old Array. Not New/Old Element and index of element.
The plan is to determine which element of the array and which item of the cluster changed. Big reason I'm changing to Bool. Updated VI....
The other issue here is I have no idea of how the cluster will change going forward. I thought about using the number output from bool to number as an enum... but that wouldn't work in this scenario as each item added to cluster would be added to end of cluster thus causing that enum to change significantly. Better to drive by item in cluster.
If you are using an event, you can get old a new value from the event data node. Do a != comparison set to "compare aggregates" inside the FOR loop, and search the resulting 1D boolean array for T. Then use the returned index to get the element from the old a new array if you need to find the changed element.
(edited for clarity 😄 )
@altenbach wrote:
If you are using an event, you can get old a new value from the event data node. Do a != comparison set to "compare aggregates", and search the resulting 1D boolean array for T. Then use the returned index to get the element from the old a new array and compare further in a similar way.
Is that not what I'm doing? I guess I search for the "True" by changing to number and looking for Greater than 0. That part probably not necessary. Could just OR array. Okay, so that's something. Still, just wondering if there was a function or something that determines and returns index of changed element.
Updated:
@LuminaryKnight wrote:
@altenbach wrote:
If you are using an event, you can get old a new value from the event data node. Do a != comparison set to "compare aggregates", and search the resulting 1D boolean array for T. Then use the returned index to get the element from the old a new array and compare further in a similar way.
Is that not what I'm doing? I guess I search for the "True" by changing to number and looking for Greater than 0. That part probably not necessary. Could just OR array. Okay, so that's something. Still, just wondering if there was a function or something that determines and returns index of changed element.
Updated:
What you are doing is fine. I think you are worrying about efficiency/execution speed for the wrong thing. If using clusters, then you can only have 256 elements, I believe. That (256) is a lot of elements for a front panel control. Determining the changed item for a 256 sized list/array/cluster should not be an issue.
Sorry, here's what I had in mind. (less clutter inside the loop)
Your code (on average) will make significantly more comparisons. It always compares all elements first (unless the compiler can untangle it 😄 )
You still need to be careful, for example if the array size can change, e.g. if the user would add a new element at runtime, more code is needed because you can no longer autoindex on the old array because the loop would stop early.
@altenbach wrote:
Sorry, here's what I had in mind. (less clutter inside the loop)
Your code (on average) will make significantly more comparisons. It always compares all elements first (unless the compiler can untangle it 😄 )
You still need to be careful, for example if the array size can change, e.g. if the user would add a new element at runtime, more code is needed because you can no longer autoindex on the old array because the loop would stop early.
I've got the "new element" scenario resolved. Only applies to arrays of equal size. And I see what you did. Cleaner. Thank you.
