An alternative idea for the For Loop Iterator representation

[GregSands]

Seeing the latest discussion on controlling For Loops (and those others referenced) has helped me define what I would like to see, so I present this as an alternative idea for consideration.

My thoughts reduce down to two requirements:

1. that the underlying iterator must (by necessity) be an integer
2. that often I want to be able to modify that iterator in the way I use it

Having said that, I don't particularly like the configurations (such as "Start, Stop, Step, N", or "N-1-i") suggested so far which add further clutter to an increasingly complex structure (N, P, i, conditional terminal, shift registers).  So here's my suggestion:

1. Loops always have an integer iterator, but that representation should be selectable up to U64 (either by a right-click-menu or by wiring N with the desired type).  I'd be equally happy with only a U64 iterator (why do we have a signed representation for a quantity which cannot take a negative value???)
2. The available value "i" is then defined from the loop iterator.  By default, it equals it, with the same representation.  Changes to this are achieved with a "docked" subVI (which might look something like a timed loop input node) that is defined in an analagous way to a VI for the NonlinearFitting routine.  It has one input: Parameters; and one output: i, with the values of N and Iterator also provided to it in some way.  The representation of the output "i" is what is then available in the For Loop through the iteration terminal.

So the output of this example would give the array [-20, -10, 0, 10, 20]:

I think this arrangement gives some benefits over previously suggested ideas.  The complexity of manipulating the iterator is embedded in a subVI which can have an icon to show its function (not hidden in a property menu).  All of the control is on the left side of the loop, and there is still only a single iteration terminal with the symbol "i".

[JackDunaway]

Again, I'm Kudosing this Idea for traction in the For Loop Improvement Movement, but I still like Smart Iterators with Loops since it embodies the cleanest syntax thus far for configuring a For Loop.

Also, this statement is dubious: "that the underlying iterator must (by necessity) be an integer". Yes, Manzolli points out legitimate risks with using a floating point iterator, but those risks can be understood and mitigated for the sake of a cleaner Block Diagram and fewer coercion dots. I'll concede, dodging potential heartache (one LabVIEW pillar) by only allowing integer iterators could be reason enough to not allow floating point iterators, but I wouldn't rule it out as being by necessity an integer.

[GregSands]

What I mean by "that the underlying iterator must (by necessity) be an integer" is that you cannot have iteration 4.74712893 (for example).  The iterations themselves are sequentially numbered as integers from 0.  What my idea suggests is a way to alter that iteration number to give any useful number - the mock-up diagram shows a floating-point number - from the iteration terminal.  The way of converting between the iterator and the terminal is given by the docked subVI.

My problems (even though I Kudos'd it!) with Smart Iterators with Loops is that it (a) adds 3 more terminals to the loop, and (b) is restricted to a simple linear change in number.  What if you wanted the logarithm of that value?  Or a more complex function which then needs to be added into the loop anyway?  You might as well also include the 2-3 nodes required to generate a ramp sequence.  Or what if you wanted the number of values to be determined by the automatically-indexed array, but to work with some function of that index?

I'm trying to suggest a way to bundle that information into a programmable unit, which is simple and flexible.  I know it is always possible to put a subVI after the iteration terminal and get the equivalent effect - this is just a suggested way to move it outside the loop where it really belongs, with the associated lazy-evaluation of the "array" of iteration indices.

[CrystalTech]

I also like the Smart Iteration but not the iteration conversion as you propose.  The conversion is a mere addition of a conversion function which also tells you what the conversion is.  Much Kudos to the Smart Iteration, but I simply do not find enough of a strong argument for the conversion idea.

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.