LabVIEW Idea Exchange

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

Select Comparison Function accept array for its Select input

Status: New

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.

 

9 Comments
Knight of NI
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)
Active Participant

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

Primitive Select where S is Array

Dragis
Active Participant

I would have found this useful a few times.

JÞB
Knight of NI

Highly Kudosed!

 

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


"Should be" isn't "Is" -Jay
AristosQueue (NI)
NI Employee (retired)

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
Trusted Enthusiast

@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!

 





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
crossrulz
Knight of NI

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
AristosQueue (NI)
NI Employee (retired)

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

JimChretz
Active Participant

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