Change the numeric representation of iteration terminals in Loops in LabVIEW 64-bit to 64bit integers.

[PrimaryKey]

As in the title the numeric representation of iteration terminals seems to be wrong in LV 64-bit. Why is it Representad by 32 bit integer. Doesn't it seem like a problem when iterating through VERY big arrays (size supported only in 64 bit LabVIEW) not to be able to track all of the iterations?

 This is how it is now. Should be 64 bit (no typecast)

[tst]

You might wish to look at this idea - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-array-index-representation-to-U64/idi-p/1178689

In any case, unless the array index representation is changed to I64, there's no point in changing the iteration terminal, especially when replicating the behavior of the iteration terminal only requires a feedback node and an increment primitive.

[Mr.Mike]

We shouldn't do this to just 64 bit.  We'd need to do it to 32 and 64 because otherwise it would require changing the types on the VI when loading a 32 bit VI in LV 64 and vice versa.  If you load a VI (in the current version), run it, and close it without changing anything you shouldn't need to save changes.  

[JLewis]

I think we'd have to make it configurable. For FPGA applications, we usually would rather have a much smaller type there. Forcing it to 64 bits would be unacceptable.

[vitoi]

What about right clicking the iteration counter and selecting its (integer) representation?

[TomOrr0W]

Kudos specifically for vitoi's modification to allow selecting representation.

[AristosQueue (NI)]

Summary: This idea should have been declined a while back. It was explicitly evaluated and rejected for LabVIEW NXG.

Details:

> Doesn't it seem like a problem when iterating through VERY big

> arrays (size supported only in 64 bit LabVIEW) not to be able to track all

> of the iterations?

LabVIEW does support arrays that take "greater than 32-bit" amounts of memory but not arrays requiring "greater than 32-bit" indexing. In other words, you can have an array of very large data (clusters of many integers, for example) that goes far beyond the 32-bit limit, but you can still only have 2^31-1 elements in that array max. That is a limit we would like to lift but it requires a complete rewrite of the code generator, the compiler, and all supporting DLLs because the size of an array is a part of the array's data, and that is widely assumed to be a 4-byte signed integer.

With no need to autoindex, the question is whether we need to cover very large iterations. We certainly could, but in talking with users, there wasn't much of a need for it -- not enough to justify the development cost. That includes the FPGA case of making the iterator smaller -- useful, but not useful enough. So NXG retains the 32-bit limited For Loops.

Since R&D has explicitly evaluated this, I will submit this idea to be declined.

[Darren]

Declined for reasons listed in AristosQueue's post on this thread.