I am stunned by TestStand suport engineer's answer to my bug report?

Question

Okay, my HTML is bit rusty. here it is.
So, I ran into this problem that when I put a continued inequality expression (a<x<b) in a Pass/Fail step, it will always pass. This is very easy to duplicate, say you have a local varible x = 3, in a Pass/Fail test step's Data Source Expression you put "0<=Locals.x<=2". Then it will always pass when you run it. If you set b to less than 1, say 0.5, then it will always fail. So I reported this as a bug to NI support. Here is what I got for explanation:
NI support/application engineer:
"I was looking into this behavior further and what is actually happening is that for "a<=x<=b", the program is evaluating a<=x, returning 1 if true or 0 if false, and then checking if that 1 or 0 is <=b. This is why a pass was always returned by your code. I still think that recognizing the continued inequality expression would be a good addition to teststand, so i will suggest this change to R&D."
me:
"In that case, it's just simply wrong (as a bug would cause) since it assumes that b is somewhere between 0 and 1. I don't think that TestStand should check the Boolean return value from evaluating a<=x against b, that does not even make sense or someone did not know what he was doing. It should be reported as a bug, not a feature request for future release."
NI support/application engineer:
"I'm sorry that you feel this way, but this syntax would be executed in the same way by any programming language. the <= or < operators are treated like any operator such as * or +, and so this behavior is completely expected by order of operations. just as a*x*b would find a*x, then apply that result to {result}*b, a<x<b calculates the result of a<x (1 or 0) and applies that result to {result}<b. I do understand your frustration, but this is not a bug; it is completely expected behavior. Please let me know if you have any other questions about this issue."
me:
"Do you really want me to spell this out to you?! I would feel embarrassed if I were you. But you insisted, so here it goes.
You are correct that these operators are treated the same in any programming language. Here is where you got lost, read this again - "just as a*x*b would find a*x, then apply that result to {result}*b, a<x<b calculates the result of a<x (1 or 0) and applies that result to {result}<b."
Why in the world that you would substitute variable x with the result from evaluating a<x for the second comparison x<b?
The answer is that "{result}<b is just NOT the same as x<b". Do you see the problem now?
Do you know the difference between a Boolean and an integer? 1 and 0 can be used to present a Boolean, but when you plug it in an integer comparison and it will be used as an integer which throws the whole comparison out of water. I don't think that any other programming language would do that."
NI support/application engineer:
"I am very sorry that you were not satisfied with my explanation of the problem. I understand that this result is not desirable, but the underlying reason is that TestStand does not understand that you are trying to compare a<x and x<b in the same statement. The continued inequality is an implied conjunction of two comparisons, and TestStand (and other programming languages) do not know how to interpret this implication. I realize that this is not intuitive, and though I would agree that a<x<b seems like it would return 1 if x is between a and b and 0 otherwise, this is not a recognized syntax by TestStand and other languages."

Answer 1

Hi CT,
I agree with you completely that this may be undesired behavior depending upon exactly what code is being written. Thanks for bringing to our attention any behavior that seems undesired, we always want to know about these types of things!
I ran the pseudo code "a<x<b" where a, x, and b are numbers in a few different environments:
VB6: This returns true for any x value.
C#: This does not compile, due to a type mismatch.
C++: This returns true for any x value. 
C: This returns true for any x value. 
LabVIEW: Using comparison functions, this results in a broken wire due to a type mismatch 
LabVIEW: Using a MathScript Node, this returns true for any x value.
I would say, generally speaking, it is accepted behavior to
type cast a Boolean result to an integer when the next function
requires integer parameters. In every language, using  the logical AND operator, as Jigg suggested, removes any chance of ambiguity between the coder and the compiler.  
The good news is that the product suggestion that the support engineer filed on your behalf will still be reviewed by R&D. So, whether this is a bug or a feature request, it will get its due attention.
Message Edited by Evan P. on 10-15-2008 08:25 PM
Evan Prothro
RF Systems Engineer | NI