New tunnel mode: Build set

[BertMcMahan]

I searched but didn't see this idea yet. I'm surprised it hasn't already been suggested.

The idea is to add a "Build Set" to the Tunnel Mode menu:

Right now we have to build an array in the loop, then convert it with another loop. A native menu option, with the ability to keep the Conditional checkbox, would be very useful.

(Similar thread: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-native-functions-to-convert-between-1D-Arrays-and...)

[wiebe@CARYA]

>Right now we have to build an array in the loop, then convert it with another loop. 

Why do you need a 2nd loop? You can put Insert Into Set in the first loop, and use a shift register...

[BertMcMahan]

True. My main use case is with the conditional mode tunnel. You would need to either use a second loop or add a case structure that selects whether or not to add the value to the set. Even without the case structure, it still takes up a bunch of space where you have to wire the shift register throughout the loop. It's just a lot smaller and neater if it was built into the tunnel itself.

It's basically the same argument for autoindexing tunnels in general. Yes, you can build an array with Build Array and a shift register, but it's neater and simpler to autoindex the tunnel. This is just expanding that same practice to Sets.

[AristosQueue (NI)]

I can't find it, but I know this has been discussed on the forums. It was discussed extensively when sets and maps were being designed in R&D. We axed it because of issues of representation on the diagram -- there's just not much room on the tunnel for iconography. Since the performance of a collection building terminal would be the same as the shift register method (unlike arrays where tunnel notation can let us do some performance optimizations that are hard to detect from code analysis), we let it slide.

[Neil.Pate]

I think this idea is a bit too niche and the will result in more noise in the menus which are in desperate need of thinning out already.

Auto index on arrays is something that will probably be used 100x more (probably greater than this actually), so is a sensible use case.

Just my opinion though, and mostly driven by the fact that very little of my code uses sets!

[AristosQueue (NI)]

> mostly driven by the fact that very little of my code uses sets!

I think that may be mostly an accident of history. I'm watching sets eat a fair amount of array code. Never going to dominate over array indexing, for sure, but becoming common enough to warrant the autoindexing tunnel? I'm starting to think yes. We only have two years (since LV2019) worth of usage data at this point, but the uptake rate of the sets (slower than maps) is still high compared to most new features.

[BertMcMahan]

I feel like this would help increase the use of sets. Many people still don't know about them or don't consider them too much. If it was as simple as a mode on a tunnel, it might give more people pause to think, "Why's that there? Maybe I can use this instead." I don't use Sets and Maps much either but I've been trying to break old habits. When I've forced myself to rethink an older method using Sets and Maps, I've always found it's MUCH better than my old ways. Sets don't replace ALL of my array usage, as 90% of it is data handling anyway, but they definitely make a lot of operations much simpler and neater.

[avogadro5]

If this is implemented would it be compatible with iteration parallelism?

[AristosQueue (NI)]

avogadro5: I suspect yes, but won't really know until we sit down and study it.