Best practice: For loop or Condition structure and increment variable?

[Nyala]

Hello,

I am currently editing someone else LabView code and I noticed at several places the use of "home-made" for loops instead of the structure provided by LabView. What I mean by home made is just incrementing a variable and checking that it is below N, the number of iteration required, with a case structure.

I found it weird, and I would like to know if there is any reason to choose one option or the other (speed ?).

Thanks a lot,

[altenbach · Accepted solution]

If the number of iterations is known before the loop starts, it should typically be a FOR loop, not a WHILE loop.

However, the N input and the iteration terminal are I32 and for fast loops with many iterations, you'll run out of values and a FOR loop no longer works. If the loops needs to run for more than ~2^31 iterations, you need to do your own using a WHILE loop, e.g. increment a I64 integer in a shift register and terminate after the desired number of iterations.

[wiebe@CARYA]

Also noticeable, before LV11 (OTOMH, IIRC), there was no conditional stop in the for loop. So as soon as your loop had a premature stop, you had to refactor your for loop to a while loop. 

That could account for "checking that it is below N, the number of iteration required, with a case structure". But not the "incrementing a variable", as 'i' could still be used just fine.

Another thing to consider is that the programmer just didn't know what (s)he was doing. That happens . Hard to say without seeing some code...

As for speed, I'd always use as much of the build in loop functionality as possible. It's usually hard to beat.

[crossrulz]

---

wiebe@CARYA wrote:

Also noticeable, before LV11 (OTOMH, IIRC), there was no conditional stop in the for loop. So as soon as your loop had a premature stop, you had to refactor your for loop to a while loop.

---

That feature was released in LabVIEW 8.6.  I abused the FOR Loop Conditional Terminal and the Linked Tunnels in a major project with that version.

[wiebe@CARYA]

---

@crossrulz wrote:

---

wiebe@CARYA wrote:

Also noticeable, before LV11 (OTOMH, IIRC), there was no conditional stop in the for loop. So as soon as your loop had a premature stop, you had to refactor your for loop to a while loop.

---

That feature was released in LabVIEW 8.6.  I abused the FOR Loop Conditional Terminal and the Linked Tunnels in a major project with that version.

---

Probably mixed it up with the conditional autoindexing...

[altenbach]

Well, we probably would need to see some code for final judgement on the sanity of the discussed approach, such as datatypes, etc.

Be aware that if you do a >2^31 iteration "fake FOR loop", certain things no longer work right. For example you cannot autoindex at an output tunnel because all arrays are limited to I32 in the index (and thus the number of elements cannot be larger than that) even if you have infinite memory and LabVIEW 64bit.

[Nyala]

Hi Altenbach,

First of all, thanks for this complementary information. I understand that it would have been preferable to put some code but I am afraid that the actual code is ways too complicated to be really helpful here...

I accepted your solution because it seemed to be the only reason for why one would prefer a "fake FOR loop" rather than the LabView structure "FOR loop", even if obvious memory problems might occur in such a situation.

I guess that, for my specific situation, what might have happened is the person who made the original diagram was more used to low level languages than LabView.

[altenbach]

On a related note, if you look at my benchmarking examples (running averages tester), you'll notice that I use a fake inlined iteration count that is U64 because we would quickly run out if I32 causing wrong results.

(Note that this implementation is oversimplified and assumes that the loops are on the toplevel diagram and don't repeat. In the more general case they would need a reset mechanism)

[wiebe@CARYA]

---

@Nyala wrote:

 but I am afraid that the actual code is ways too complicated to be really helpful here... 

---

---

@Nyala wrote:

I guess that, for my specific situation, what might have happened is the person who made the original diagram was more used to low level languages than LabView.

---

Makes me lean even more to "redundant complexity"...

You could try to either reduce an example to the essentials, or post fragments. Or post it all, we've probably seen worse.