LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

For loops that can auto index beyond the end of the shortest array

A right click option for each auto indexed array that allows will not use the length of that array in choosing the number of iterations. If there is no input to the count terminal all auto-indexed terminals can go beyond their length otherwise at least one must remain as a driver for determining the length. If multiple are left with the default (existing) behavior, the shortest length will be used. For any iteration where the array is shorter that the "i" of the loop, the defaults for the data type will be returned (just as if "index array" blocks had been used inside the loop. 

 

Similarly the loop could be set to use the longest array instead of the shortest.

 

Additionally a similar function could be done when any array compare or math functions are done. In the case of compare functions if set to use longest array, the result will be false for any compare to an empty element of the shorter array, and math functions will use the default data type for empty elements.

9 Comments
Trusted Enthusiast

That are two different ideas.

 

The for loop option would save one Index Array (per array). Not sure how I feel about it. It sure can be annoying from time to time.

 

Autoindexing.PNG

This will always iterate 10 times, no matter what the array sizes are. The red color of the indexing is just an example, it could probably be improved.

Proven Zealot

Can you explain why you want this? What is your use case for needing to index arrays of different sizes? I've been inclined over the years to call it a bug that LV allows the arrays to be different sizes from each other or to differ from the N value. What problem are you trying to solve?

Member

I agree it would be nice if you tried to index outside of the array bounds (or had different length arrays) without setting the proposed modification it should throw a run time error or something. but seeing as they have not done that in the past and instead just pretend like it all worked just fine when in fact it truncated some of your arrays can really bite you if you are not careful.

 

I have had several instances over the last few years where I knew my data was of different lengths but wanted the ability described. I have had to manually index inside the loop which just takes up space and is tedious.

 

One instance I can think of (for the function request) off the top of my head is putting two different length arrays into a "=" function and the array that comes out is all true but they are different lengths. In the proposed idea (for functions) it would have false for all elements beyond the end of the shorter array. 

 

 

Trusted Enthusiast

One use case is optional VI inputs.

 

So you have an array with values, and one or two other inputs that are arrays, but optional. When not wired, the defaults are used. This is most useful for Boolean arrays, but also numerics when 0 as default makes sense (like offsets). Even classes, when the class is an array of functors, and the default does nothing.

 

I'm not for or against the idea; all it saves is one index array. I do admit that when developing, once in a while I miss this kind of behaviour. But it doesn't happen that often. Really haven't made up my mind about this...

Proven Zealot

Weibe: Can you show  me a block diagram where you are autoindexing over both of those arrays in the same For Loop? I think I get it, but I want to be sure.

Trusted Enthusiast

I've searched for all my for loops, but stopped at 700... I gave up searching for an example from the wild. Apparently, I usually find ways around it. It's not very elegant...

 

But here's a mockup:

Optional Auto Indexing.PNG

 

Just for completeness: this would save the caller from doing things like this:

Optional Auto Indexing usage.PNG

  

Knight of NI

See also this much older idea and  point #4 in my 12 year old post here. Smiley Very Happy


LabVIEW Champion Do more with less code and in less time
Trusted Enthusiast

I'd say this one is duplicate then?

Example Gatekeeper