Allow Select Function to accept an "Index of" numeric input

[topside]

I think it would be useful if the select function could accept a numeric "index of" input in order to choose between the 2 chosen inputs. Let me explain further using the first diagram in this example:

When using the "search 1D array" or "match string pattern" functions I have to use a "Less than zero" function to then feed into the select function to ensure the value is only passed through if it exists in the array. What I believe would be useful is if the select function would allow you to wire numeric values to the (what is now) Boolean input, and take any positive number as true and any negative number as false (I realise this kinda breaks the rule of binary). Alternatively I think a purely numeric select function would also be sufficient. I think this will help the block diagram to become slightly less cluttered and save some space, as well as being much quicker to produce.

I am posting this idea as it is a method I use frequently, though there may be a more efficient way of doing this that I have not picked up on - If so I am open to comments.

This could also be taken further in using the same approach in while loops for instance.

I realise some may not be keen to use a numeric approach as you will have a much larger variation in data (as opposed to the beauty of Boolean) however the terminal would ignore the variation and simply choose between positive and negative to make a decision.

[Darin.K]

That particular use of -1 is by far my biggest pet peeve with LV.  I get ill every time I think too hard about it.  The search function should return an index and a boolean indicating whether or not the element was found.  That boolean would feed straight into your select function.

The only behaviour that makes sense to me for feeding a number into the select function is for zero to be false and anything else true.  It is a cute syntactic shortcut in C, but I do not miss it that much in LV for the Select primitive.

[tst]

An alternative solution to your specific problem would be for the search primitives to have a mode where they return a Found boolean instead of the index or if they just always return a boolean as an additional output.

[AristosQueue (NI)]

> That particular use of -1 is by far my biggest pet peeve with LV.  I get

> ill every time I think too hard about it.  The search function should return

> an index and a boolean indicating whether or not the element was

> found.  That boolean would feed straight into your select function.

My observation is the opposite. If you split that into two outputs -- the index and the boolean -- you end up with folks who only use the index and don't check the boolean at all, resulting in even stranger run-time errors than the -1. I wouldn't mind adding the boolean output, but I'd still want the index to return -1.

But then I realize that the reason I wouldn't mind adding the boolean is because, as a language primitive, if you don't wire the output, LV will not generate the code to populate that output... if this were a regular subVI, I wouldn't want to calculate the boolean because it might not be needed by the caller. Having a different convention for the prims vs regular subVIs would be odd. Which brings me back to not wanting the boolean on the primitive.

Basically, I could be talked into adding the boolean, but not into changing the not found value of the index. And that applies to all similar functions across the LV spectrum.

[Darin.K]

The unfortunate use of -1 is too established at this point, but I will never, ever, ever consider that to be good software practice.  I still have to hold my nose when I use it.  Be that as it may, I was not suggeting that, just adding the boolean output.

Whoever slipped this one into vi.lib does get bonus points in my book.

[AristosQueue (NI)]

> Whoever slipped this one into vi.lib does get bonus points in my book.

But I bet the index is still -1 if not found, given that the output is an int32.

[Darin.K]

> But I bet the index is still -1 if not found, given that the output is an int32.

Nope.  (What do I win?).  I32 probably just avoids future coercions.

[AristosQueue (NI)]

> What do I win?

That good feeling that comes from being right.

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.