12-12-2012 10:33 AM
Is there a way to do the following (or at least this stuff in the box) generically. Is there a name for this algorithm?
Essentially I want to reduce an array to just its elements that pass a test. The test can just be another array of booleans which say whether the array passed the test or not. I feel like I write this code a lot and it bothers me that I write it so much.
Thanks!
Solved! Go to Solution.
12-12-2012 10:42 AM
What version of LabVIEW are you using?
If you are using 2012, there is a conditional index on output tunnels (right click on the tunnel to configure). That would eliminate the need for the second loop.
If using an older version, OpenG has a "conditional index" VI that will perform the action you have in your box (the second loop).
12-12-2012 11:25 AM
So the OpenG guy creates a array of variants on the output which of course kinda kills compile time type checking and then of course you have to go and convert it all back which doesn't take quite as much space as the original diagram but it's still not a one drop solution like it should be. Hopefully we can upgrade to 2012 soon! Thanks!
12-12-2012 11:32 AM
Let me suggest the slightly more clever approach shown below, where you re-use the input array. If you make this into a subVI with the input as an array of variants, you can use it on any type of data at the cost of adding Variant to Data after the subVI call. Conversion to and from variants incurs minimal and will have little effect on performance.
12-12-2012 11:33 AM
@crossrulz wrote:
That would eliminate the need for the second loop.
The second loop is never needed. Do all in one loop! (even without conditional indexing tunnel!).
How big are the arrays? If performance matters I would not use the conditional tunnel. There are plenty of examples in the forum how do do it nearly in-place.
12-12-2012 02:05 PM
Thanks all for the responses.
I find it so frustrating that Labview sometimes can't even do things that are so simple in other languages (see like http://docs.python.org/2/library/functions.html#filter) or that can be trivial to implement in other languages (see C++).
My hope was that no variants would be necessary at all as they add clutter and bypass compile time type checking. Clearly one way to make functions like this generic is to use variant data. I was kinda hoping to avoid it all together. The reason I wrote out the function the way I did is because it's space and time efficient in more cases, generally.
It's true you're probably fine doing this in one loop (using a preallocated array with the same size as the input array). Consider though that if you want to avoid making a full sized copy of the array, generally, seperating out the loops is needed. Labview doesn't make a copy of any array data until it passes the data into the test function (and if the test function isn't even a vi then it doesn't make a copy at all) which it will only do one or P at a time, depending. Then the only new allocation of significance is the allocation by initialize array, which in many cases will be substantially smaller than the input array.
This time the performance doesn't matter. But I'd sure like to make generic functions like these that could be generally performant. One day maybe.
12-12-2012 02:19 PM
majoris wrote:
I find it so frustrating that Labview sometimes can't even do things that are so simple in other languages (see like http://docs.python.org/2/library/functions.html#filter) or that can be trivial to implement in other languages (see C++).
When you find a language that can do everything easily and efficiently, please let me know and I'll switch to it immediately! 😉
I agree with you that it would be nice to have generic operations on arrays in LabVIEW, but I suspect that would require major changes to the ways arrays currently work.
12-12-2012 04:28 PM - edited 12-12-2012 04:31 PM
What you should do is e.g. generate a list of indices to ber retained, .i.e. do all processing operations on I32.
Now only the final reassembly needs to depend on the original datatype and will be very fast. (of course you need slightly more code, because you have a slightly different problem)
Here's part of the code I had in mind (read the entire discussion thread. Lot's of useful information).
For a generic solution suggestion, see my idea discussion here. (we are not there yet!)