Select Comparison Function accept array for its Select input

[SteveP]

Allow the Select comparison function to accept an array as its S Select input.  This would allow the result of an array comparison to be followed by the Select function and if that array were then wired to one of the Select T or F, would allow each array element to then be replaced individually based on the separate boolean result.  One of the Select input (T/F) would be allowed to be a scalar so the array element could be replaced by that one value if desired.  This capability would provide an alternative to performing this operation with a For Loop and take up less diagram space.

[smercurio_fc]

You're mixing two ideas and redefining the operation of the Select function. Is the Select supposed to select between two data sources, or replace? The Select function was never intended to be used for replacement of anything, and I don't think it should.

[JCC_(SK)]

I will find it very useful when Select primitive will support array s control. It will make block diagrams smallest.

[Dragis]

I would have found this useful a few times.

[JÞB]

Highly Kudosed!

Select should have a "Comparison Mode" Right click option like any other comparision

[AristosQueue (NI)]

It wouldn't need a Comparison Mode. In fact, a Comparison Mode would be meaningless. It just needs to be polymorphic on the inputs. If the middle terminal is an array, all terminals must be arrays. If the middle terminal is a scalar, it has the behavior it has today.

As a member of R&D, I have no problem with this idea. If it gets enough kudos, it is totally doable.

As a LV user, I don't like it. Putting a For Loop around a node is not a substantial burden and I generally prefer the readability of the code without these sorts of overloads *when multiple terminals get involved*. So I'm in favor of things like Close Reference becoming polymorphic to accept an array of refnums; and I'd like for Property Nodes to accept an array of refnums, but I wouldn't want the properties themselves to then become an array. There are too many times when things have gotten confused about how many elements are in the two arrays. At least the Property Node has error terminals to report a mismatch. The Select node does not.

[crelf]

---

@AristosQueue (NI) wrote:

It wouldn't need a Comparison Mode. In fact, a Comparison Mode would be meaningless. It just needs to be polymorphic on the inputs. If the middle terminal is an array, all terminals must be arrays. If the middle terminal is a scalar, it has the behavior it has today.

As a LV user, I don't like it. Putting a For Loop around a node is not a substantial burden and I generally prefer the readability of the code without these sorts of overloads *when multiple terminals get involved*.

---

Agreed!

[crossrulz]

So if the True and False terminals were forced to be scalers, you would be fine with the idea?  This is the situation I have most found myself in when wanting this feature.

[AristosQueue (NI)]

Crossrulz: IMO, that would be better. I still wouldn't vote for it myself, but I wouldn't oppose it happening.

[JimChretz]

I'd accept scalar on the inputs even if the selector is an array, why not?