Smart Iterators with Loops

[Dragis]

LabVIEW loops are quite flexible and allow me to do just about anything I want, but I often find myself writing the same code over and over again trying to iterate across different data types and data structures. There are several situations where smarter looping constructs could greatly simplify my code. One simple example is stepping by a delta between a minimum and maximum value. Currently, I have to calculate the number of iterations required ahead of time (for a for loop) or do a comparison with the maximum (with a while loop) and use shift registers to maintain the intermediate value. I'd like to be able to wire the max, min, and delta to my loop and have LabVIEW do the required calculations for me. The iteration terminal could also adapt to the proper data type given the input parameters. Perhaps the iteration terminal would have two outputs, one with the current iteration count and the other with the proper iteration value.

 

Another useful feature would be allowing me to wire a queue reference to the loop count terminal of the for loop and having it automatically pop each value from the queue and feed it to me through the iteration terminal. It would do this until there are no values left in the queue or until the code stops the loop. One could write an algorithm that pushes new points into the queue from within the loop or push the current value back onto the queue for later processing.

I'm sure there are other useful iteration strategies that are fairly common, please share them with the community. 

[ibberger]

you guys know that you request the same thing, the "build ramp pattern" function allready does!?

[crelf]

I'm with tst - LabVIEW ships with a ramp function that you can use to generate the array that you're after and you can then feed it into the loop.  Sure, having the loop handle it might be nice, but as a workaround exists (and has been used for years), I'd prefer NI R&D to concentrate on some of the other ideas here.

[altenbach]

The current ramp function is "min, max, N", not "min, step, max" or "min, step, N", etc.. As a first step (no pun!), it might be useful to make the ramp polymorphic so we can chose how we want to define the ramp.

Still, I would prefer to have to ramping option in the loop itself for the following reasons. Syntax compatibility with other programming languages that can already do that (mentioned elsewhere). Especially for large ramps, allocating a huge DBL array to later just index over it might also suck up a lot of memory while the loop could allocate a single DBL in place for the same thing. Definitely more lightweight. 🙂

[JackDunaway]

Some further discussion has been percolating on Reverse Iteration Terminal in For Loop.

Specifically, what terminals should be offered, and what they should be called.

Basically, there are three degrees of freedom that need to be constrained with a choice of four different parameters: pick any three from begin value, end value, step (increment value), and N (number of iterations).

Personally, I would find the most use in begin, end, and step. Number of iterations is less interesting, and using this value typically involves pulling out a calculator to derive one of the other values.

Example: I want to count from 100 to 0 by -5. If I was required to input "N" instead of "step", my inclination would be to enter 20 even thought 21 is the correct number of iterations (it's easy to mentally omit the +1 when thinking about arithmetic series).

[JackDunaway]

Also, from the other thread (linked above), I suggested changing "max" and "min" to "Begin" and "End". altenbach countered with "Start" and "Stop", which I like better.

Start, Stop, Step, and N flow together well as the names of the four parameters available to constrain the loop.