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

[CT]

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."

[~jiggawax~]

Hey CT,

I'm sorry you didn't like your experience with NI Support.  They are considered one of the best in the country and are generally spot on.

You could do "0<=Locals.x && Locals.x<=2".  That will fix it.

The reason this is not a bug is because the < and > operators take integer values as arguments and return booleans.  Therefore, the returned boolean is typecast to an integer for the next evaluation. 

So in your case the 0<=Locals.X gets evaluated and returns as either a 1 or 0 then typecast to a numeric.  Then it is compared with the 2.  So this will ALWAYS return true.

Hope that helps clarify,

[CT]

Well, it took me about 10 seconds to figure out an workaround after I spotted the problem. I think you fell the same trap that the support engineer did. The point I tried to make is that the reason it is a bug is because you just can't simply typecast the result boolean to an integer for the next evaluation. How hard is it to recognize two comparisons and logic AND the results? Don't get me wrong, I agree that NI's support has been top notch since I started using LabView during the Windows 3.1.1 days.

[Evan P.]

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

[CT]

Thanks for your effort, Evan. Now, let's step back for a second. The whole idea of having the ability to be able to write an expression is to not use conventional programming language syntax (even it's a high level one like C++). I understand that TestStand expression has its own rules just like any other language, but at a much easier level. Hence there is the error check button. Now, if the error check says the expression appears just the same as in any algebra textbook is fine, but it will give you a totally unexpected result and "it is accepted behavior"? I had worked as a programmer in a commercial software firm for a few years, but I never had the attitude/mentality that it's okay for my code to give undesireable result only because everyone else is doing that. May be the software engineering practice has been changed.

[~jiggawax~]

Hey CT,

In the TestStand Reference manual it states: "TestStand supports all applicable expression operators and

syntax that you would use in C, C++, Java, and Visual Basic .NET."

So I guess if it works in those languages then it should work here.  If these languages contradict then they may have a problem but it looks like Evan tested most of them and they did the same thing as the expression in TS. 

I really learned something from this issue.  I probably would have assumed the same thing as you but it makes sense from you conversation with the AE why it is the way it is.

Good luck with you sequences,

[richjoh]

OK, the type casting of a<x results in True for the expression, a<x<b.

In TestStand is the expression enclosed in brackets, (a<x<b), valid to work around the typecast. Does this result identical to the a<x && x>b expression.

[~jiggawax~]

How would that change anything by putting the parenths around it?  It does not change the typecast and will yield the same result.

[snowpunter]

CT,

Essentially, your desire is that TestStand developers change the software's functionality to fit your particular use case. The fact of the matter is that there are 3 logical operators (&&, ||, and !) and you would like TestStand to read your mind and implicitly use only one of the three every time? That doesn't seem fair to the other two, they have feelings too.

If they bended to your will, how would they explain to the other users whose use cases call for one of the other 2 operators? I suppose they could have 3 different versions of TestStand, one for each use case, though the naming scheme might be difficult to maintain. You might make a product suggestion out of this.

Message Edited by snowpunter on 10-16-2008 11:26 AM

Message Edited by snowpunter on 10-16-2008 11:31 AM

[CT]

snowpunter,

Let's put your feelings aside for a minute (I assume that you have used Windows long enough and not to get it too personal).
If you actually read my first post, you could see the mention of continued inequality. It's an algebra term and it's okay if you missed that class, it does not take a whole lot to grasp the concept. So here it is: By definition (as in algebra), a continued inequality a<x<b means a<x and x<b.
Here is the question to you: out of the 3 logical operators (&&, ||, and !) , which one you like to use for a<x<b?
Will you just bend over to use whatever TestStand wants you to use?

Message Edited by CT on 10-16-2008 12:52 PM