Allow multiple elements to be connected to Element of Set?

[PNR]

Element of Set? returns whether a single element is a member of a set. In order to check multiple elements, we currently have to place multiple nodes on the block diagram, which is rather redundant:

I would like to be able to connect multiple elements to a single node and check all elements at once:

As an example, I need to check if either of two elements is part of a set. If one of them is, add the other, otherwise do nothing:

This is certainly not a deal breaker, but in my opinion it makes sense to allow multiple elements to be connected to this node, especially considering that it is read-only.

[PNR]

> I read the posted .vim as a solution for the 1, 2 and 3 input.  It seems to be just that, but I can't actually open it to review. I assumed the TSS is used to assert the inputs if 1 or 2 are not wired. I don't understand why else the TSS is there.

My bad, that was my first VIM and I thought the TSS was mandatory. It turned out not to be 🙂

All inputs on the VIM are actually set to required. There is another VIM for two inputs with the same setup.

> An XNode might do the trick, but that's a little more work than a VIM.

Indeed, that would work. XNodes are, however, not officially supported by NI, which is why they are no option for me.

[wiebe@CARYA]

Ok, so you can make a .vim with 3 inputs, let's say Booleans (because a Boolean input for a map makes little sense). Than you can use a TSS to check if the input is valid for the map type. That would make a check for 1, 2 or 3 (4 or even 5) inputs. The TSS will make the unused inputs do nothing. Than you'd have one VI to check 1-5 inputs, without overhead for the unwired inputs. Unless you use a map of Boolean type. Hypothetical, I'll have to install LV19 or higher one of these days.

This seems more practical to me compared to a VI for each number of inputs.

[PNR]

> Ok, so you can make a .vim with 3 inputs, let's say Booleans (because a Boolean input for a map makes little sense). Than you can use a TSS to check if the input is valid for the map type. That would make a check for 1, 2 or 3 (4 or even 5) inputs. The TSS will make the unused inputs do nothing.

You are right, that does work.

> This seems more practical to me compared to a VI for each number of inputs.

It depends. While a single VIM takes care of all possible configurations, you need to be careful with the outputs. If you forget to disconnect an output after disconnecting an input, any logical operation that follows could produce incorrect results. This is a bug waiting to happen which I'd rather avoid by enforcing the use of two separate VIMs.

[wiebe@CARYA]

The TSS can take care of that by forcing the output (Boolean) to be something else (like a string) if the input isn't used. Anyway, no need to debate options...

[AristosQueue (NI)]

> This seems more practical to me compared to a VI for each

> number of inputs.

A two input and a three input would cover every case I've seen in other programming languages that I can think of. Anything larger than that is an array, which you can process in a For Loop (noting that polymorphism to an array of elements would be nice, with modes to control whether the node outputs an array of bools, a single "all" bool, or a single "any" bool).

[Yamaeda]

It doesn't accept and/or adapt to an array on the lower connector? It'd be quite obvious it should be able to take an array and check "Do these string exist in the set?", though it's easy enough to make such a VI.

/Y

[AristosQueue (NI)]

Yamaeda: That was cut because we could build the compound operation later as a VIM. You'll find a number of compound operations that aren't supported directly in the primitives. We explicitly created primitives as simple as possible and as focused on their one task as we could make them. More sophisticated libraries can be built later... we wanted to be confident that we could thoroughly test the functionality that we were delivering.

There was an additional issue with taking an array -- it immediately made people ask for the different output modes of "one bool for ALL are members", "one bool for ANY are members", or "array of bool for each input element". There wasn't a clear winner for the default.

Given those two things, we left it out to wait for feedback from users about what higher level functionality is needed and how it should be packaged.