High Low Terminal for In Range and Coerce

[RavensFan]

The In Range and Coerce function is frequently used to determine whether a value is within range of an upper limit and lower limit values.

But when it is out of range, you often also want to know whether the value is out of range too high, or out of range too low.  It is easy enough to add a comparison function alongside and compare the original value to the upper limit.  It's another primitive and 2 more wire branches.  But since comparison is one of the primary purposes of the In Range and Coerce function, why shouldn't it be built into it?

The use case that made me think of this that as come up in my code a few times over the years is with any kind of thermostat type of control, particularly one that would have hysteresis built into it.  If a temperature is within range (True), then you would often do nothing.  If it is lower than the lower limit, you'd want to turn on a heater.  If it is higher than the upper limit, than you'd turn off the heater.  (Or the opposite if you are dealing with a chiller.)

Request:  Add an additional output to In Range and Coerce that tells whether the out of range condition is higher than the upper limit, or lower than the lower limit.

(That does leave the question as to what should the value of this extra output be when the input value is within range.  Perhaps, the output should not be a boolean, but  a numeric value of 1, 0, and -1, perhaps an enum.)

[crossrulz]

I would vote for the enum.

[Manzolli]

I think the output can be an additional terminal (for back compatibility), numeric value (I32):

• In range: 0
• Out of range too low: -1
• Out of range too high: +1

The nice thing about this output is symmetry. 

The advantage of the Enum would be the literal meaning of the output:

• 0: In range:
• 1: Out of range too low
• 2: Out of range too high

Even though we can create a VI with this additional output, the Include/exclude limits would need a double work and double attention.

Kudos!

[crossrulz]

You could also add to the enum "Not A Number" to handle the case with the input or limits being NaN.  If going the numeric way, I guess the output could be NaN for any floating point inputs, and therefore the output would need to be the same as the input.

[JÞB]

OK, I looked into this a bit.  It seamed like a custom user utility would be easy to write- Then I started Playing with NaN.  NaN is coerced in all cases (expected) and the output is NaN. NaN is not Greater than the UL, Lower than the LL nor equal to either the LL UL or coerced value.  That makes "Rolling-Your-Own" a bit more challenging! especially without "Generics"

Kudos

I like Manzolli's implementation idea considering that the output (Coerced?) could be made to "Adapt to output type" where wiring to a bool type node would behave historically and wiring to a signed int type node would add the desired functionallity (With Blue coersion dots as appropriate)

[dgdgomez]

I agree with the idea of Manzolli, although I prefer to change the boolean indicator "in range?" by a numeric indicator adapted to the type of input data where:

• Equal To Zero: The output value would be zero and would represent that the value is in range.
• Less Than  Zero: The output value would be a value less than zero and would represent the difference between the input and the coerce output value.
• Greater Than Zero: The output value would be a value greater than zero and would represent the diffetence between the input and the coerce output value.

In this way, depending on the output value by the "in range?" indicator, we can take different control strategies or discriminate between alarms or warnings.

[wiebe@CARYA]

When NaN is wired to the value, it should not be in range nor to high nor to low. A 3 value enum might not be enough...

This is very pragmatic:

 

And now we have .vim's it's possible to make.

[AristosQueue (NI)]

At first, my instinct was that if you're using In Range & Coerce for the situation described in the original post, you're reaching for the wrong tool. So I drew some diagrams. At the end of it, I can see the In Range & Coerce could provide a minor amount of code consolidation. There is some minor performance hit in a double compare when you only need one at a time, but it's trivial enough for most systems, so probably not a real negative.

I thought maybe there was some big breakthrough in parallelism or something, so I drew that out to evaluate, but the branches are obviously mutually exclusive, so no big win there.

In short, it isn't something I would advocate for -- I think the "if > else if <" is better notation, but I can see how someone might like it.