Real For Loop

[tbob]

With text based languages, the For Loop has a programmable starting index, stopping index, and step size.  With Labview, the starting index is always zero and the step size is always 1.  It is not changeable.  I would like to see Labview have a real For Loop where there would be three terminals inside the For Loop that can be set by the user.  One terminal for initial value (starting index), one for final value (stopping index), and one for step size.  This would be of great value to all Labview programmers.  Of course the terminals can be much smaller than what is displayed in the picture.  One or two letter terminals, such as ST for start, SP for stop, and SZ for step size would do fine.  (or N for initial value, F for fnal value, and S for step size).  The real for loop should be capable of going in a negative direction, like starting at 10, ending at -10, with a step size of -2.

[TCPlomp]

One phylosophical question. How would the for loop function when indexing an array?

Currently there is a 1:1 relation, a For Each.

When we have 5 elements, and we define our step size as 2, and we auto-index. How many times will the  loop run? (I don't even want to discuss which elements are indexed). It just feels wrong.

[Intaris]

5 times, but i will go from 0..2..4..6..8.

[JackDunaway]

Ton, I havn't considered all the implications, but perhaps auto-indexing should force an implicit step of 1. In other words, auto-indexing combined with a custom step size could be imposed as one of the overconstraints that breaks the VI. This imposition is not required in theory, but might be a logical choice as a design spec to keep LabVIEW data "dummy-proof".

And I will contend again, autoindexing and the Start/Step/Stop For Loop are almost mutually exclusive in practice in my coding style.

[Darin.K]

My current workaround for most cases is the Ramp VI, with LV10 it got much better with the addition of a new version which takes start/stop/step.  Not a fan of the chosen terminal pattern (a result of polymorphism), but I'll adjust.

I still would like to see the Reverse Iteration terminal and the option to hide any and all terminals.

[Intaris]

Why should step size have an effect on which elements of an autoindexed array are processed.  I don't get it. I think someone's over-complicating something.

Step only affects values of i, not the items indexed (unless you want to index the input array manually - i.e. not autoindexed).

[JackDunaway]

Spoiler

Darin.K, seeing your little snippet made me laugh. 😄 It seems we're all cooped up in our own camps on who wants what with For Loops, and we keep politely bringing up our own desired implementations in all the For Loop threads. Perhaps I should create my own For Loop thread? 😉 Would it be justified, given the concepts of implicit parameter assignment to maintain backwards compatibility?

[JackDunaway]

---

@Intaris wrote:

Why should step size have an effect on which elements of an autoindexed array are processed.  I don't get it. I think someone's over-complicating something.

Step only affects values of i, not the items indexed (unless you want to index the input array manually - i.e. not autoindexed).

---

Good point, Shane. Maybe auto-indexing is always "for each" and constrains N, in which case you could still assign zero, one, or two of the following of Start, Stop, or Step. I'm now leaning toward "no" on imposing a required implicit Step=1 when autoindexing.

[tbob]

If we had the option to display the 3 terminals or just the N terminal, then when wanting to use auto-indexing, just set the option to just display the N.

Now what if someone wanted to auto-index every other element (just the evens or just the odds)?  We recently had a post on the forum where the user wanted every 3rd element.  He had to write special code to do this.  With the step size terminal set to 3 and with auto-indexing, he would get every third element without any extra coding.  If you want plain old auto-indexing as it is now, just set step size to 1.  Let the auto-indexing function determine the stop point, just as it now determines the N.

We can have it all.  Just vote for the idea.

[Intaris]

Some of us don't want it all.

Complexity != Progress

I also don't recall a suggestion to have a step size affect the indexing of loop elements.  That's certainly not what I understood from this idea.

[tbob]

If you don't want it, you don't have to use it.  The default would be to display the N and act just like it is now.  The added features (3 terminals) would be enabled only if you right clicked on the border and select that mode.  Just like you right click to show the condition terminal.  If you don't want to use the condition terminal, you don't have to do anything.  Nobody was against that idea.

We would all have the option to do what we want.  Get it?  And in this case, I call it progress since it would give us more functionality, equivalent to text based languages.  The complexity is minimal.

The step size affecting the indexing was not part of the original idea, it was added on later by a suggestion.  Again if you don't want to use it, don't use it.  But let those that want it have it.

Does not everyone see that with all the suggestions made to make the extra terminals optional (like the condition terminal), that everyone can have it their way.  How many ideas promote that?  I can't believe that there are arguments against this.