10-15-2008 05:47 PM
10-15-2008 06:35 PM
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,
10-15-2008 07:06 PM
10-15-2008 08:24 PM - edited 10-15-2008 08:25 PM
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.
Evan Prothro
RF Systems Engineer | NI
10-16-2008 10:11 AM
10-16-2008 10:55 AM
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,
10-16-2008 10:55 AM
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.
10-16-2008 11:06 AM
10-16-2008 11:24 AM - edited 10-16-2008 11:31 AM
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.
10-16-2008 12:49 PM - edited 10-16-2008 12:52 PM