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]

While it is a nice idea, it would directly interfere with the implementation of this nice idea. I need to think about that a bit more....

[tst]

Personally, I didn't vote for the other idea because I prefer explicit code and having LV treat inputs as required when relevant, but with additional logic the two ideas probably could live together (for instance, by having the terminals keep their names but function correctly if a user wired incorrectly. Then, if one of the terminal is unwired, it treats the function according to which terminal was wired to).

[AristosQueue (NI)]

> Can anyone else think of one?

I can easily imagine that someone uses a lower bound of some impossible value that never happens unless they get coerced and using that to monitor when their bounds cross. We would definitely have to add mutation code to maintain the old behavior... I don't think we could call this a bug that we were fixing.

I'm not sure how I feel about this. It rubs me the wrong way, but I can't honestly say why.

[crossrulz]

>I'm not sure how I feel about this. It rubs me the wrong way, but I can't honestly say why.

I feel exactly the same way.  Though, I have been known to use the Max & Min to make sure my UL > LL.  Maybe it could be a right-click option, off by default.  Still not quite sure.

[tst]

> I can easily imagine that someone uses a lower bound of some impossible value that never happens unless they get coerced and using that to monitor when their bounds cross.

Either I don't understand you or you didn't understand me. The lower bound in this case isn't just some value which you're never supposed to get to. It's actually LARGER than the upper bound, so it's impossible to have a value which will be within the bounds. I don't see how it makes any sense. The only reason I brought up potential legacy code was because I figured someone might have been using value dynamically, and these could in theory produce an invalid state (but I can't think of a good reason for that).

I agree that this isn't a bug, per se, but I find to be highly undesirable behavior, which doesn't serve any real purpose.

[tst]

> Maybe it could be a right-click option, off by default.

Nah. For one thing, we don't need another modifier. For another, the whole point here is that it's easy to make a mistake. If you're aware of the issue, you might as well fix it yourself in your own code.

[Darin.K]

About once per year I disagree with something tst suggests, and I was about to make it through 2013.  I like my primitives to be primitive, ie. lean and mean.  This one is already pushing the envelope.  I will update my benchmarks to newer LV, but at one point the '&' in In Range & Coerce was important.  If I only wanted In Range, it was faster to write it out than to use the IR&C primitive.  Either the coerce part was not being optimized away properly, or it was not short-circuiting optimally.  Whatever the reason, the bundling of operations inside the primitive caused some performance loss.  I would prefer to avoid another operation being shoved under the hood, and I think explicitly wiring a Max & Min is better than yet another semi-hidden option or glyph.

The real solution here IMO is not to tweak an existing function, but to fix the root problem.  The root problem is that the immediate and obvious solution here is to simply write a subVI to combine the two operations but that is often not acceptable.  What is wrong with the immediate and obvious solution?  Of course it is the loss of polymorphism.

When will we see Generic controls, or the like for quick and painless polymorphism?  I am pretty certain the first digit in the version will be a 2, the second digit I am less certain about, probably a 0, the third digit is probably not a 1, but if NI wants to spite me there I would get over it. 

[X.]

Alternatively, have VI Analyzer test for static inputs to comparison primitives and return a warning when potential problems exist as shown in the example or:

and throw in test for things like that too, while you are at it:

[Darren]

---

@X. wrote:

and throw in test for things like that too, while you are at it:

---

The VI Analyzer Toolkit 2013 has a test called "Redundant Boolean Operations" that checks for this scenario.

[X.]

Indeed, but it doesn't catch this:

How complex would it be to add tst's case and those I suggested above to the list? There are certainly more potential "unused code" than just those...