LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
SteenSchmidt

New modes on auto-indexed input array tunnels in loops

Status: New

Hi,

 

Today a For-loop iterates the number of times that the smallest number of these specifies:

 

1) The N-input on the For-loop.

2) The smallest number of elements among auto-indexed arrays wired to the For-loop.

 

I sometimes want the For-loop to run longer than the smallest input array, while still needing to index through the smaller input arrays (resulting in a similar effect as when you run out of array elements when auto-indexing array inputs on a While-loop). Of course the smaller arrays will start outputting their default values when you move past their end, but some algorithms benefit from that. Today I have to do something like this (very simple example):

 

LargeAuto.png

 

It would be much simpler to be able to auto-index any input array but then also select which tunnels shouldn't be taken into account when calculating N. You know, somehow being able to defeat or deactivate the indexing limit of some auto-indexed tunnels:

 

SmallAuto.png

 

There might even be three modes of auto-indexed tunnels:

 

1) The usual mode as today.

2) An unlimited mode, as I suggest above, which will ouput the default value when running out of elements.

3) A recurring mode that would start over on the array when reaching its end (I think I've seen this mode suggested somewhere before?).

 

Thoughts?

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
7 Comments
elset191
Active Participant

Your proposed recurring mode was suggested by altenbach here

--
Tim Elsey
Certified LabVIEW Architect
SteenSchmidt
Trusted Enthusiast
@elset191: Exactly, thanks. /Steen
CLA, CTA, CLED & LabVIEW Champion
altenbach
Knight of NI

Over six years ago (and way before the ideas exchange! ;)), I proposed "dominant" indexing tunnels that determine the iteration count even if some other indexing inputs have shorter or longer arrays. (See point 4 in my post here). This seems related to your "unlimited" mode but has the advantage that we only need to single out one of the tunnels. In your idea, you would need to configure all other tunnels for unlimited, which is more work.

 

Still, I agree that something along these lines could be useful. 😉

SteenSchmidt
Trusted Enthusiast
@Altenbach: You don't agree enough to kudo it then? ;-) If it is the current or the unlimited that should be the default tunnel mode is a matter of preference. I rarely use more than 2 or 3 auto-indexed tunnels on each loop structure, so setting one or the other doesn't matter much to me. Staying with the current behavior as default would be much simpler in terms of backwards compatibility/code version migration and will ease the adoption of this new feature. I also in 99% of the times find it very convenient that just by wiring an array to the For-loop it automatically defines N. That wouldn't be the case if "unlimited" was the default. /Steen
CLA, CTA, CLED & LabVIEW Champion
altenbach
Knight of NI

> @Altenbach: You don't agree enough to kudo it then?

 

Sorry, I forgot while trying to find that old reference link.... 😄 (In my defense, it was also after 2am here....:o).

 

Yes, a simple "Right-click..ignore size for autoindexing" would already be better than nothing. I am still not sure what the best way is, so the kudos is more for doing "something" in this direction, without endorsing any specific implementation. 😉

AristosQueue (NI)
NI Employee (retired)

I generally do not like these ideas unless we move to something other than tunnels because there just isn't enough visual space to represent alternate forms and add glyphs to them that explain what is going on. With the conditional indexing, we added a new terminal and thus expanded the space of the tunnel. Looking at Steen's images, I could not tell what was different between the top image and the bottom image until I adjusted the contrast on my monitor. Even then, the gray on the bottom terminal is really ambiguous.

 

If we start bolting Index Array to the sides of the loop -- similar to the way it is bolted in the Inplace Element Structure -- then this might be viable, as we could show different configurations for the Index Array.

 

Lots of variations to change how indexing is done might get my kudos, but not the "let's just configure the tunnel differently" variety. The diagrams just aren't comprehensible past a certain point, and we're already well into the gray zone with the existing features, IMHO.

SteenSchmidt
Trusted Enthusiast

@AQ: My gray tunnel was just a way of telling the two tunnels apart - I'd surely suggest a different glyph instead of just a nuance difference. But those are details I'd expect getting sorted out in the comments or by the implementors at NI. The idea itself is separate from the artwork.

 

I thought about numerous ways to let a new structure replace both the For-loop, the While-loop, and the Inplace Element Structure. Make it configurable enough and a new structure could do it all. But the compromise would be readability. We instantly recognize a While-loop and a For-loop for instance. So instead I chase this idea a bit further - please bear over with me for a moment 🙂

 

About tunnel artwork; One of the things I like about tunnels is that they are so compact. I think it would be a big mistake to exchange them for something as large as Index Array as in the Inplace Element Structure. I agree that glyphs can be too compact, but there were never a problem destinguishing between auto-indexing and non-auto-indexing tunnels. Those two glyphs are easy to destinguish between. The current LV2012 output tunnel is no problem either I think, again it's easy to destinguish between the different modes of the tunnel.

 

Similarly we could configure the input tunnel in case it is an array tunnel (no configuration of other data type tunnels). Currently we have two configuration options for an input tunnel: auto-indexing or non-auto-indexing. These two options could be expanded with two additional options giving us, among other things, a solution to this idea. For instance:

 

Tunnels.png

 

So, basically the first two options ('Entire Array' and 'Indexing') are the ones we know today. 'Indexing' could then be expanded by enabling 'Indicate Last Element' which should go True when the last element is being indexed. That option would allow a While-loop to exit at one or a Boolean combination of auto-indexing array input tunnels running out of elements, exactly mimicking a For-loop where you could select which auto-indexed tunnel N inherits from, and thus solving my feature request (albeit with a While-loop).

 

The last option ('Repeating') would be altenbachs idea of an auto-indexing array tunnel starting over and over upon running out of original elements.

 

I think that would be pretty easy to grasp, while not being that far from the artwork of today?

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion