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.

[Manzolli]

LabVIEW has only integer as counters because it's not safe use a float for this purpose (Do not use floating point variables as loop counters: https://www.securecoding.cert.org/confluence/display/cplusplus/FLP31-C.+Do+not+use+floating+point+va...).

The type of data on the "For Loop" structure [N] terminal is a [I32]. Any negative number causes the same effect as a zero. How about having the countdown effect when the terminal [N] receives a negative number? Even though the [N] receives a negative number, the [i] should show a positive countdown sequence, for example: N = -5, then will be i = 4, 3, 2, 1, 0.

[Intaris]

@Altenbach:  Oops, yes you got me there.  Of course "P" is a very important one.....

[JackDunaway]

@Manzolli: Interestingly, that coding guideline has been marked as obsolete and tagged in the VOID category. The "Risk Assessment" parameters at the bottom of the page also show that floating point iterators are a subjectively "low risk".

I won't argue that choosing an integer datatype for an iterator would be considered as a "best practice", but this does not altogether preclude the floating point iterator.

Virtual Kudos for that link.

[JÞB]

@ all-

I DO understand your frustrations with the arbitrary limits placed on the LabVIEW native For Loop's itiiration.

Yet, It's simple interface (NO HIDDEN PROPERTIES) are one of the reasons the NI LabVIEW IDE is so approachable by novices!  The "work-arounds" are simple enough and really just basic-  why add a barrier to grasping a LabVIEW base structure's interface?

Keep it "so easy a caveman can do it!"  and <Flames are going to come> Let us developers "take a penalty" for creating advanced functiality.   Heck- I developed a pseduo binary search algorhythi 10 years ago in LabVIew 5.1! 

I think "Making it easier" in this case may make it less approachable. MHO

[cgibson]

In the absence of a good example, I think I have to agree with Jeff. It has been a long time since I used some of the more esoteric For loop ideas like count down and stepping (Obvioulsy in other languages), but I haven't missed them.

While I agree that the work around is clunky, it can be cleaned up. Instead of calculating the reverse index every iteration, calculate the first value outside the loop, use this to initialize a shift register, decrement the shift register value every iteration. If you don't like the wire running across because of the shift register, use the old style feedback node.

[Manzolli]

The problem of using floats for counting is the fact of the imprecise representation of some real (float & fixed point) numbers in binary. When a lot of calculations are made, like in a For Loop structure that adds a increment every loop, the accumulation of small errors can became something important after many iterations. This can be worse when the limits and increment are results from calculations, not constants. The most common problem I had in the past, with other languages, was having an extra loop because in the last desired iteration the result is almost the limit, like 4.99999998 instead of 5.0. The best workaround is to compare the final value with the maximum acceptable error, like: abs (end – i) < error.

Thanks for pointing that JackDunaway. I'm really not sure if this is still an issue in nowadays hardware and software. When I started, long time ago, it was. Actually NI should check if then can safely implement the float version.

Good point Jeff Bohrer. But if they implement it as an extra, like the conditional and parallel terminals, keeping the default way that the For Loop structure appears when is placed in BD, I think it's fine.

[GregSands]

Here is an alternative idea for computing a floating point iteration terminal from an integer iterator, which gets around the accumulation problem.

[Intaris]

I've done something terrible....

I've revoked my Kudos because I have to agree with recent discussions that this is a sign of us just getting lazy as programmers.  What's wrong with creating the values outside of the loop and then auto-indexing the resulting array?

[Manzolli]

When I started using LabVIEW I missed the float For-Loop common in many other languages: INITIAL, FINAL and STEP, that works with any float value, including negatives. Soon I realized that integer counter forced me to do good program practices. Since then, I just calculate outside loop the first value and step, and inside multiply [i] by the step and add the first value. Pretty obvious and easy to do. Agree with Intaris. We want everything ready done by NI. Are we becoming just a bunch of lazy block connectors? Maybe NI is spoiling us... LOL

[Darin.K]

Ok, I am lazy.  When I wire three different arrays to a For Loop I should just add an array size for each one, build an array of those values, find the minimum, use that to calculate N, decrement it, pass it to a shift register, and then use that value.  Or cross wires everywhere because my calculation of the reversed values is pinned to the upper right corner.

The other ideas, floats, start/stop/step are completely, utterly, and entirely separate. I am happy to have raised the discussion, but I am afraid it muddied the water of this very simple idea.  

For the record, my opinion on the other changes is as follows.  The Ramp VI solves most of the problems.  What is under the hood of this very simple VI, a Call Library Function.  This seems an admission by NI since they have to resort to C for this very simple operation.  I'd love to see them publish the source, a for loop in there perhaps.