Reverse Iteration Terminal in For Loop

[Darin.K]

It has been a few months since a suggestion has been made to do something about the For Loop, so if nothing else it is time to stir things up a little bit.  There have been several suggestions to do something with the iterators, for example:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-Iterators-with-Loops/idi-p/967321

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/for-loop-increment/idi-p/1097818

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Start-Step-Stop-quot-structure-on-For-loops/idi-p...

None of these has really gained traction, and heck, I haven't settled on any of them myself.  In most cases I am satisfied with a workaround, usually involving the Ramp VI.

There is one case where I am not happy with the workaround.  I happen to need reverse iteration values quite often (N-1,N-2,...0).  With the N terminal pinned to the top-left corner I have little choice but to do the following and start zigging and zagging wires:

I would simply like a reverse iteration terminal which can be moved around at will and simply counts down.  Doesn't have to look like I have drawn it, that just happens to be intuitive to me.  Naturally this terminal (and the normal iteration terminal) should have the option to be hidden.

I thought about having the option to have the loop spin backwards, similar to reversing all auto-indexing inputs and having the iteration terminal count down, but I just could not decide what to do about auto-indexed outputs.  My G-instincts tell me that they should be built in the order of loop cycles, my C-instincts tell me I am building array[i] and if i goes in reverse order, so should the array elements.  For now I say, forget it, and just stick to the simple terminal.  Array reversal is essentially free, so I at least have a workaround there.

[Intaris]

Darin,

there's no need to take the shortest array at all.  Take any at all because if your step size is known, the autoindexing takes care of the rest for you.  It certainly can't be any less than the smallest.  In the worst case you calculate a few index values too many which get ignored by the for loop.

And if you don't know which array to be taking as a reference for your indexing, then I suggest the problem lies elsewhere.

[JackDunaway]

---

@Darin.K wrote:
The other ideas, floats, start/stop/step are completely, utterly, and entirely separate

---

Yes, integer/float data representation is completely separate, No, the Start/Step/Stop/N is not separate at all. This can be used to accomplish what you want. Set Start=10, Stop=0, Step=-1. Then, implicitly, the "i" terminal is your requested "i--". Implicit, because you can look at the sign of the "Step" terminal.

The benefit of this implicit designation is that the graphic of the iteration terminal never needs to change or be configured.

And I don't think any of the For Loop Improvement ideas have anything to do with laziness. If there is a cleaner syntax to accomplish the same task, cleaner syntax always wins. Bottom line: $$$ to develop and troubleshoot gives a better overall value to the developer's billing hours if the developer is able to configure and synthesize faster.

Also, as altenbach pointed out elsewhere, there's less overhead/memory requirements associated with a native iterator rather than generating a Ramped Array. Negligible, probably, but less is less.

Looking at the following comparison, which one is easier to understand and troubleshoot? This conversation should arguably be happening in that other thread, but I still hesitate to drop the comparison between this idea and the "Smart Iterators" idea.

[Darin.K]

Still trying to get this point across without getting into gory algorithmic details.

Start-Stop-Step requires me to know the number of iterations, why should that be?  LV will know what N is regardless of how it is determined.  The example with multiple arrays is to demonstrate that it is not always trivial to determine N.  And besides, why re-create a calculation that LV is about to do for you?  Show me an example of how the Smart Iterator construct will autoindex an array and give me a countdown and I will stand corrected.

There are a number of cases where I need or want to work from both ends of an array.  This makes it trivial.  Sometimes you need to work on an array in reverse.  Reversal is free, but perhaps you still need to know an elements position in the unreversed array, again trivial.

[MonteF]

Here's an idea for more control of the for-loop iterator, and rather than create another idea entry I thought I'd add it to the most recent entry. 

Can there be terminals on the "i" icon that allow a user to initialize and set the increment size of the iterator?  The terminals could even be left unconnected with default behavior just like the current for-loop.

This can give almost all of the flexibility that users want without changing much about the look or feel of the for-loop.  This allows initializing the start of the iterator, adjustable and non-integer sized steps, and decrementing.  The one difference between this and other for-loops with which users are familiar may be that users are required to know the number of iterations to execute rather than the termination condition or end value.  Perhaps that could be an option also, perhaps like one of these:

Or perhaps that functionality can be restricted from the for-loop and available only with a while-loop.

[tst]

This sort of configuration should really not be inside the loop. It's the kind of thing that should be configured BEFORE the loop starts running.

[MonteF]

---

@tst wrote:
This sort of configuration should really not be inside the loop. It's the kind of thing that should be configured BEFORE the loop starts running.

---

Yes...configured BEFORE the loop starts running, then the iterator's input terminals are ignored when the loop is running.

Maybe the inputs can be required from outside the loop if that reduces confusion.  Or the iterator can be anchored to the corner of the loop like the "N".

[Intaris]

Anchored yes, floating no.

But somehow I just don't like having to have items at the top-left and bottom-left of the for loop.  Makes for a lot of re-alignment if the for loop needs to be resized.....