LabVIEW Idea Exchange

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

Add native functions to convert between 1D Arrays and Sets

Status: New

We currently need to use for loops to convert between arrays and sets:

Current Situation.png

This is not a bad thing in principle, but in my opinion there are multiple issues with it:

  1. These loops require a lot of space on the block diagram, which distracts from the *actual* code. The for loop provided on the palette in particular is absurdly large (and has a label attached to it). Most users probably won't use it more than once.
  2. The same code is used in many places to do the exact same job. This is a strong indicator for reusable code in the form of SubVIs.
  3. An empty for loop can confuse users who are new to sets.

I think LabVIEW should ship with malleable VIs to take care of conversions between 1D Arrays and Sets, because everyone who uses sets will need them eventually:

Suggested Solution.png

Download All
7 Comments
AristosQueue (NI)
NI Employee (retired)

The current set up is intentional, as discussed elsewhere (I'm pretty sure it is in the documentation, but definitely elsewhere on the forums). I will leave the idea open to see what kudos it accumulates, but there is definite bias against adding the functions. Converting between set and array frequently requires some amount of filtering of the elements. Adding a function that does the conversion straight up leads to the very inefficient pattern of "convert" and "filter" as two separate passes over the data (significant number of data copies and memory cache hits).

 

I will acknowledge that while converting from set to array is a pretty small node (just a For Loop with two autoindex tunnels, which shrinks down to nearly the same size as a subVI node), going the other direction is substantially more code (since at this time there is no autoindex tunnel mode that accumulates into a set). Thus there is a stronger argument for adding "Array To Set.vim". But in my personal opinion, that just argues more for a new autoindex tunnel mode.

 

PNR
Member
Member

The current set up is intentional, as discussed elsewhere (I'm pretty sure it is in the documentation, but definitely elsewhere on the forums).

 

Any pointers are welcome. I have difficulties finding good results because of the generic meaning of the term "set".

 

Converting between set and array frequently requires some amount of filtering of the elements. Adding a function that does the conversion straight up leads to the very inefficient pattern of "convert" and "filter" as two separate passes over the data (significant number of data copies and memory cache hits).

 

Good argument. A Malleable VI could indeed lead to people thinking that it is *the* way to convert between sets and arrays. As you said, the For Loop can be made pretty small, so this isn't a deal breaker.

 

Thus there is a stronger argument for adding "Array To Set.vim". But in my personal opinion, that just argues more for a new autoindex tunnel mode.

 

Interesting. That would allow sets to behave the same way in both directions (from and to arrays). The only issue I see is that sets can't contain duplicate elements, so there must be a way to know if an element was (or can be) added. Not sure how that would work with indexing tunnels.

wiebe@CARYA
Knight of NI

>Any pointers are welcome. I have difficulties finding good results because of the generic meaning of the term "set".


https://en.wikipedia.org/wiki/Set_(abstract_data_type)?

PNR
Member
Member

https://en.wikipedia.org/wiki/Set_(abstract_data_type)?

 

That much is clear.

 

I was hoping for links to the forums regarding the intention behind the current implementation of sets. AQ mentioned that is has been discussed elsewhere but I'm unable to come up with anything useful.

wiebe@CARYA
Knight of NI

Ah, so the specific meaning, not the generic meaning 😁.

 

I just added LabVIEW to the Set (abstract data type) wiki...

AristosQueue (NI)
NI Employee (retired)

I don't recall where I posted it, but it's just what I said above about filtering and performance.

BertMcMahan
Active Participant

@AristosQueue wrote:

But in my personal opinion, that just argues more for a new autoindex tunnel mode.


I found this thread searching to see if "New tunnel mode" was in the Idea Exchange yet, and only found this thread and this comment. So, I started a new idea for this concept.

 

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-tunnel-mode-Build-set/idi-p/4169443