LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Conditional auto-indexing

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
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.

Proven Zealot

> 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.

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.

 

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

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...

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.

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

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.

NI Employee
Status changed to: In Development
 
NI Employee
Status changed to: In Beta