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.

[AristosQueue (NI)]

*laugh* Where were you during the beta program? Literally, no one suggested that. In retrospect, it is such an obvious request. Unfortunately, what would have been an easy "yes we should do that" during the initial design is a much harder sell now: there's code mutation and documentation churn, which make the return-on-investment argument harder to make. This idea will have to run the gauntlet against other ideas. But I do like it. I'll add my personal kudos.

I will also mention it to the LV NXG team... they haven't done the first version of those nodes for their platform yet.

[AristosQueue (NI)]

As a workaround, you could create a malleable VI that has two inputs, and another that has three inputs. I doubt that you'll commonly need more than that.

[PNR]

Thanks for the insight. I was wondering if this was considered but dropped because of some implementation details. I'm glad to know that this is not the case 🙂

Malleable VIs are a great suggestion, haven't considered them. Indeed, two or three inputs are enough for most cases and the solution is also straight forward. Here is mine with three elements for anyone interested:

[wiebe@CARYA]

I almost suggested this. The only problem is there is no input type that can't be used as an index for a map or set. So you might be creating overhead. In your example, the default type is a string, so unless you use something else, it will perform 3 lookups.

I tried to use an array with no type as input. The .vim works, the typeless array on the front panel is not a problem, if the terminal is in a type specialization structure. However, the .vim can't be used unless you wire the typeless array. If this was accepted, we could have a 'not wired' type (or hack or workaround).

[AristosQueue (NI)]

> so unless you use something else, it will perform 3 lookups.

What algorithm would *not* perform 3 lookups?

[wiebe@CARYA]

>> so unless you use something else, it will perform 3 lookups.

>What algorithm would *not* perform 3 lookups?

The TSS could detect if only 1 input is wired. then it will only do one lookup. But there is no type that says 'not connected' (although a Boolean doesn't make much sense here). If a array without type could be used, that will signal 'not connected'.

[PNR]

> The only problem is there is no input type that can't be used as an index for a map or set. So you might be creating overhead.

How so?

The .vim reliably breaks if types don't match. The only overhead is the need to use three different nodes to do the same job (which is why I prefer the original node to accept multiple elements). Depending on the desired number of "concurrent" lookups I use one of these:

By carefully naming the .vims and with the power of QD, this works well enough for me. Here is my example from above with a .vim for two elements:

 

> The TSS could detect if only 1 input is wired. then it will only do one lookup. But there is no type that says 'not connected' (although a Boolean doesn't make much sense here). If a array without type could be used, that will signal 'not connected'.

You should open an idea for that.

In this specific case, I wouldn't use the vim for a single lookup. That is what the original node can do just fine. In fact, my implementation of the .vims requires 2 and 3 elements respectively. You are not able to use them with a subset of elements. Again, I would rather have the original node accept multiple elements in the first place.

[AristosQueue (NI)]

@Weibe If you didn't want three lookups, don't drop the "three inputs" VIM. Drop a "two inputs" VIM or the "one input" primitive. No one suggested that the VIM could replace the growable node feature requested here, only that it could aggregate the multiple nodes currently required.

> The TSS could detect if only 1 input is wired.

There is no mechanism for doing that.

[wiebe@CARYA]

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.

>There is no mechanism for doing that.

I know. Not yet anyway.

An array without type seems to do that for 50%...

[GregSands]

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