LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
falkpl

Conditional auto-indexing

Status: Completed
Available in LabVIEW 2012

Auto-indexing of arrays in for and while loops are a nice luxury in LabView.  One option that could save much time would be a menu option to turn on conditional indexing, this would expose a boolean terminal under the auto-index icon to select if the current itteration should add the itteration to the array or skip it.  From an execution standpoint there would only be a minor performance hit (could still preallocate max array size on for loops and automatically return used subset).  This could also work for autoindexed in but would have less use that the autoindeded out case.  I know I have built many conditional arrays inside of a for loop and it requires a case selection and a build array making the code less readable and requires time and thought.  It can also be less efficient than a compiler can do.

 

See the example below which would run a for loop and only build array of < 0.1

 

Conditional autoindex.jpg

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
21 Comments
GregSands
Active Participant

I like this idea, but have one question: how would this work with a parallelized loop?  I imagine there could be issues with knowing how to reassemble the results from each thread into the final array.

AristosQueue (NI)
NI Employee (retired)

> how would this work with a parallelized loop?

 

I'm not one of the LV parallel loop experts, so there may be some terribly clever way to handle the problem, but at an absolute worst case, you run all the parallel loops, each of which returns an array, which it drops off in an array of arrays (same process as a plain auto-index does to drop data off in a particular index for a parallel for loop) and then LV concatenates all of them before returning the final array on the wire. So it is dooable.

GregSands
Active Participant

I imagine that makes it hard to optimise, both for memory usage and for speed, in that the size of each output array is unknown before the loop is executed, and therefore the position to write the results into the final array is also unknown.  I guess one solution may be to allocate an array of the maximum possible size, and then perform a second pass to shift valid results to the start of the array, and truncate. This would probably make the speedup from parallelism very dependent on what proportion of results were valid.

 

donkdonk
Member

I was directed to this idea by tst after I submitted my idea http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-booleans-for-array-indexing/idi-p/1309062.

Now I kudood this idea, but I suggest an alternative without a loop structure:

Boolean indexing.PNG

schuller
Member

I've posted a similar idea to solve the same problem, while I didn't know this one.

However, this is an pretty nice solution, so it gets my Kudos...

schuller
Member

One additional comment to the OpenG conditional auto-indexing tunnel:
The problem with this VI is that it only removes elements from an array which initially contains all elements, regardless of the condition.
So it does not save any memory, it's just a "post-processing" VI.
I'd like to have a VI that only collects the elements which match the condition.

David_Ferster
Member

Here's another idea for how to handle the problem of addressing arrays by content. I just posted it.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Indexing-Arrays-by-Content/idi-p/1535166

vitoi
Active Participant

I think the hard thing here is not the technical implementation, but working out how to represent it so it's consistent with the LabVIEW look-and-feel and is intuitively obvious. Still haven't seen an implementation that is harmonious with the rest of LabVIEW.

G-Money
NI Employee (retired)
Status changed to: In Development
 
G-Money
NI Employee (retired)
Status changed to: In Beta