In Range and Coerce should be more forgiving

[tst]

I just spent way too much time debugging a really stupid issue (it actually took that long because it was manifested in a specific location and there were some red herrings).

Essentially, I had code like this and I couldn't figure out why it was returning false:

The answer was simple, once I realized the problem was there - I wired the lower value (option 1) to the "upper limit" input, which means the function will forever return false.

I suggest that the "In Range and Coerce" function should function correctly regardless of which input we wire the value into (maybe by including a simple Max & Min call inside it) and that the names of the inputs will be changed accordingly.

Possible problems:

1. It's an extra comparison and possibly some pointer reshuffling, so it will hurt performance. The function already does comparisons, and it's relatively minor, so I think it's worth it.
2. It might break old code of people who did rely on this behavior. I personally can't think of a good use case for relying on this behavior. Can anyone else think of one?

[altenbach]

The function diiscussed here is already heavily overloaded and can take scalars and arrays and a mix (an array input with scalar limits for example). There there is the by element or aggregate comparison mode as well as the inclusion and exclusion of the limit values. It works even with input mixes not mentioned in the help (e.g. a scalar input in the middle, but array limits, giving an array output). A new option "sort limits" could be added, but then downconversion would be tricky.

(There are several issues with the current icon design, for example it seems too long (wide strip of whitespace in the center), and I would prefer if the middle input were aligned in height with the non-boolean output. but that's a different discussion...)

[Darren]

I have filed CAR 422917 to add a VI Analyzer test to check for the 'minimum range value greater than maximum range value' situation on In Range and Coerce. I will probably start off by having it check constants whose values can be cast to numerics, since I think that will cover most of the 'gotcha' cases where this problem happens...I'll see how much effort it is to check for other types.

[Intaris]

I would prefer a new primitive called "Between and coerce?" or something instead of changing the currently quite clear and correct definition of what "in range and coerce" does.

[NickNZ]

You would break code:

I have inherited some code that took a reference row in some data and added +- offsets to it to create limits. In range and coerce was used to compare other data rows to the reference row limits.

But sometimes the reference row had corrupted data and the easiest way to make sure all the subsequent rows fail consistantly (after throwing the "insane reference row error") was to swap the max and min limits.  

I like the VI analyser solution.

[_Y_]

Such a solution will reduce imperativity of the code (that is alwas bad, IMHO). However, the "In Range and Coerce" can be supplied with an additional property "autoselect min-max". Anyhow, there is a solution now - put "Max & Min" just before "In Range and Coerce".

[Darren]

I'm not going to have time to add the VI Analyzer test for detecting this problem to VI Analyzer Toolkit 2014. I went ahead and posted a community version to the VI Analyzer Enthusiasts community:

Swapped Range Inputs

This version will detect the scenario in tst's original idea post...two constants wired to the 'upper limit' and 'lower limit' terminals, where both constants can be coerced to a numeric type, and the 'upper limit' value is smaller than the 'lower limit' value.

[Darren]

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