Why is For/While loop Iteration I32?

[JDinkins]

Food for thought:

Is there ever a situation where you would have negative loop count? (Iteration = the blue "i" box)

Personally, I can't think of a situation where I would need more iterations than I32 max positive (2147483647 iterations).  I know that For loops are limited to 2147483647 iterations on the count input & that While loops can exceed the max count, but the iteration count stops at 2147483647.

I think it would be neat if we had the option to change the representation of the Iteration count. If so, the representation (max positive only) would determine the limits for the count input (For loop) &  for stop counting (While loop). The biggest advantage would be cleaner code, in terms of reducing the numeric conversions (to eliminate coersion dots).

Opinions?

-Jerry

[smercurio_fc]

I don't really know the history, but it seems to me that NI simply used an integer, which is fairly common practice for loop indices, even in text-based languages. E.g.:
  for (int i = 0; i < N; i++)

That's no different that the loop index being an I32. As for the cleaner code comment, why would you need more than one numeric conversion, if one was needed? You can simply branch from the output of the conversion function.

Message Edited by smercurio_fc on 10-11-2007 01:02 PM

[JDinkins]

Ok, so for loops in other languages can be expressed as, "for (int i = 0; i < N; i++)" . Can they be expressed as,  "for (uint i = 20; i > N; i--)"? Pardon my syntax errors.

But in LabVIEW, "i" is always I32, "i" always starts at 0, "i" is always compared to N with "<", and "i" always increments by 1.

 I guess NI took this approach because it was the original definition of a for loop. But wait,  what about the new conditional stop in LabVIEW 8.5? Is that deviating from the definition of a For loop? 

Sorry for the confusion on the numeric conversions. I meant to say that I often have to place one numeric conversion in a for loop (not multiple).

My original thought on this issue was, "isn't it silly to have a signed integer for the "i" count that is always positive?"

-Jerry

[tst]

Indexing functions (array indexing, string indexing) use I32 as well (you can have negative values, at least -1), so I find that I32 is better for avoiding coercions. I would suggest using I32 and DBL for everything unless you specifically need other types. Also, try avoiding coercions in loops. If possible, do the conversion once before the loop.

[tbob]

I agree that the loop count will never go negative, so why and I32 instead of U32?  I guess in this case it really doesn't matter, and it would cost time and money for NI to change this or to make it configurable.  This would not really a difference in my opinion, therefore it would not be worth NI's time and money.

However, I would like to see the loop step size be configurable, and the starting point be configurable.  If I want to start at a point other than 0, or if I want to step by something other than 1, I have to create my own loop counter with shift registers and math functions.  Having a configurable starting point and step size would be well worth NI's time to develop, I would think.

[GuenterMueller]

I wouldn't bet that it takes that long until the I32-behaviour changes. With 64bit (operating) systems getting more an more popular we will face quite soon the situation that the "native integer" will be used almost everywhere in LabVIEW, too. Why should future versions of LabVIEW insist in using I32 values if CPUs have 64 bit registers?
Guenter

[Kevin_Price]

I've wondered the same thing myself before (why a signed int for an always-positive index count?).  My best guess on it was that it helps maintain symmetry with some of the array functions.

Specifically, there are array functions such as "Search 1D Array" (and others) which return an index value.  When the function fails, it's useful to be able to return an illegal index value of -1, designating "no such index".   If those functions returned unsigned ints, they would also need to return a boolean to indicate whether or not the index output is valid.

So..., if array functions might return indices of -1, then other array functions should be able to accept input indices of -1.   Thus array indexing needs to accept signed integers.  Finally, because a common use of the iteration terminal in a loop is to index into an array, the iteration terminal is also made to be a signed int.

Just a guess, but that's how I've figured it.

-Kevin P.

[Wiebe@CARYA]

You don't need a shift register for that!

Simply multiply the I with the step size, and add a number. If you use an
expression node it will take no space at all...

Regards,

Wiebe.

[GuenterMueller]

Hello Wiebe. Your are right and your proposal is excellent. Nevertheless I like tbob's idea. C (to my opinion a very fast but somehow outdated language) allows to configure for loops in a very meaningful way. This prevents you from looking at the loop body to figure out how it works.
I would like to see LabVIEW supporting this, too.
Have a nice weekend, Guenter

[Wiebe@CARYA]

In the analogy of C, the "i" should be removed altogether from LabVIEW!

In C, you have to define everything yourself, so you'll have to do it
yourself in LabVIEW as well. This would involve using a shift register
(analog to passing a variable) and some math.

In my opinion, it's nice to have the "i" there, and if you want to use
something else, you have to make it just like you would in C.

Regards,

Wiebe.