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?

[AristosQueue (NI)]

X: Very complex. I say that with some confidence by looking at the code that does dead code elimination in the compiler, which detects these kinds of situations and kills them off. It's a fairly hefty library, and a lot of it is in LLVM, the open source compiler helper system that so many compilers are leveraging these days. I mean, consider a Double that passes through the X^2 node and then into the <0 node. That's always false also, but it takes a sophisticated analysis of multiple instruction runs to figure that out.

I'm not saying that you couldn't add more to the VI Analyzer. I am saying that making it robust enough that you could say with confidence that it caught most of them would -- I think -- be hard.

[John_P1]

---

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?

---

If you're programmatically deriving the max and min values based on some other conditions, it could be quite possible that in certain scenarios there is actually no "in range" input.

As an example, I have a use-case where my user can configure the output voltage of a power supply.  There is a fixed 150V power supply in series with the programmable one, so the minimum aggregate voltage is 150.  The maximum aggregate voltage is calculated based on other machine parameters and settings.  There are cases where the calculated maximum is actually less than 150, in which case I wouldn't allow the user to fire the machine at all until other settings are changed.  I certainly wouldn't want the max and min values to be switched at runtime!

[AristosQueue (NI)]

John_P1 makes a good point... I was only thinking about the numeric output. The Boolean output I can think of lots of scenarios for using the current value.

[fabric]

Another minor complication would be the visual association of the upper and lower limits if the inputs were switched.

The default is to include the lower limit but not the upper... Presumably "upper" means the top-most input on the primitive but it could be construed to mean the higher-valued input...

[Darren]

tst, do you think it would be valuable for me to add a VI Analyzer test to our Block Diagram > Warnings category that checks for this situation? If an In Range and Coerce function has constants wired to its limit inputs, and those can be cast to numeric values, to return a failure if the value wired to the upper limit is lower (numerically) than the value wired to the lower limit?

[Darin.K]

> John_P1 makes a good point... I was only thinking about the numeric output.

Unless I am misremembering something here I thought the numeric output already does the switch.  I seem to remember it acting that way, so to tst's point about a performance hit, the comparison is being done already....

[tst]

A quick test shows that the numeric output does already function correctly. The problem is only with the boolean output (and that's the problem I had in the original post).

There are some good points brought up - John's use case seems reasonable, although I don't really like the implicitness of "this has to be minimum value". I would probably have preferred more explicit code for something like this.

The limit inclusion is also a good point which I didn't consider for some reason. While I think the behavior on a swap is obvious ("upper" means the larger value), not everyone would necessarily interpret it the same way.

A VI analyzer test might indeed be relevant, although it should probably include strings and maybe other data types as well. A very quick test seems to indicate that comparing two variants gives reasonable results on arrays as well, so maybe you could simply use a VI with two variants, although that might have all kinds of weird behavior depending on whether you set the mode to compare elements or compare aggregates.

[ToeCutter]

I don't think the function should be changed/complicated. This is one where you should write a wrapper VI to perform any input value flipping if you want to modify the standard behaviour, IMO. If you wire an impossible range (lower limit>upper limit), you should consider the output undefined, even if it seems to return something 'useful'.

[AristosQueue (NI)]

> you should consider the output undefined

I disagree with that. If the function has a documented behavior, using that is not a bad idea.

[ToeCutter]

"I disagree with that. If the function has a documented behavior, using that is not a bad idea."

You are correct, I hadn't realised this was documented behaviour. Still, given that we support the use of documented behaviour we do not want to break the current documented behaviour which includes reference to the fact that "if the lower limit value is greater than the upper limit value, ....In Range? is always FALSE, even if x is between the lower and upper limits," as it could break existing code bases and create confusion.

So my recommendation would still remain to write your own function if you want something with different behaviour, although I have to admit the current operation seems a strange mix of functionality with respect to the numerical and boolean outputs for inverted ranges.