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

[richjoh]

Oh OK, makes sense, typecast takes precedence. TestStand has its own built in nomenclature for handling this arithmetic. You could use the "CheckLimits()" func that will return the bool if the value (x) is between a high (b) and low (a)...

[~jiggawax~]

Hey Rich,

Great suggestion.  Thank you!

CT,

I know that NI tries to make the best products they can.  And although I disagree with you on what the syntax means I think it's important for NI to get opinions such as yours.  I'm sure if you filed a product suggestion as mentioned then R&D will look it over and see if it's something to consider for next versions.

Snow,

I was a bit confused by what that had to do with the comparison opertators as well.  But I think you were using the logical operators as an example?  By the way- nice avatar- GO UTES!

I think we have several valid solutions here so lets just do what works.  TestStand does have it's issues, as no software is perfect, but it is by far the best off the shelf automation test software out there.

[Dennis_Knutson]

In algebra, the expression 'a=a+1' would be incorrect. Of course, that is a perfectly acceptable expression in programming languages. The expression you tried to use is a Boolean expression (there is a difference - maybe you missed that class) and in order to get the results you want, you have to use the && operator.

[CT]

You are right. Do you know why "a=a+1" is incorrect in algebra? Because it's not defined there just like "a<b<c" is not defined in programming languages you were referring to. If you call that you still can use it with programming language's own interpretation of order of evaluation defined, it's fine with me. So, TestStand on one hand tells me it's fine to have such an expression without defining what it does, then gives me incorrect result. I totally understand and know that I have to use "&&" in other programming languages.

[ebalci]

CT,

I think you are beating the air.

Even the first responses of the NI support should be enough to convince you. Nobody says that the behaviour is intuitive.

But that's how it works.

You probably have noticed that the expression syntax in TS is similar to C/C++, which generates the same result as TS in this case.

TS expression checker does not warn you because it checks whether the variables exist and their types are consistent. And in your case, they are. 

C#, being designed to avoid such misconceptions (like '=' not being valid in if statements), does not even compile.

This should mean something to you.

You will probably complain again that we do not understand you.

But actually it is just the opposite.

[rex1030]

Hey CT,

I don't know you or your programming background so don't be offended please. Logically speaking, you are right. To any person with a math background a<x<b is pretty straightforward. However, computers are stupid. You must tell them explicitly what you want them to do in almost every programming language. Most programming languages will perform the first operation in a true/false senario and if it is true then there is no need to perform the following operations because it is already true. What you have to do is the AND in order to force the program to perform both checks. If (X is greater than A) AND (X is less than B). The compiler uses this behavior of skipping 'unneccessary' operations to speed up the execution of the program. Believe it or not, this can actually be useful in speeding up the execution of your program if you program the most likely cases to be checked first. It can be annoying, but its just the way programming is.

[Norbert_B]

---

CT wrote:

So, I ran into this problem that when I put a continued inequality expression (a< "Result"(*) <b) in a Pass/Fail step, it will always pass. 

---

I know that this thread is quite old and only revived recently. Nevertheless, i am a little confused by the quoted part where i made a small modification (*).

The given inequality expression is a typical area for Limit Steps, not Pass/Fail Steps. So, besides the discussion about buggy behaviour of the Pass/Fail step for "stacked boolean logic", this would be the most simple solution ever. Why not use it?

hope this helps,

Norbert 

[pwaszkewitz]

Since this thread has been recently revived anyway and I stumbled across it, I would like to comment on the statement "just like "a<b<c" is not defined in programming languages". That is not correct. In fact, the ANSI C Standard as well as the C++ standard specifies exactly that behavior, for example in section r.5.9, "Relational Operators" of "The C++ Programming Language", 2nd Edition, by Bjarne Stroustrup: "The relational operators group left-to-right, ...; a<b<c means (a<b)<c and not (a<b) && (b<c)."

This may be unmathematical but the possibility to do this kind of "expression continuation" is extremely useful in C and its successors for writing very efficient code (well, OK, not this example, but it is a general behavior of the language).

TestStand has been following this convention for a long time now and as another post in this thread stated it is actually documented that it behaves like C in these expressions (so it is also not true that TestStand did not define what it does). It will certainly meet with resistance to change that behavior all of a sudden as it would break a lot of existing code, and worse: break it silently, i.e. without a configuration time error message but with different runtime results.

[david_jenkinson]

Also, it seems to me (and a little suprised it hasn't been mentioned) that a < x < b type of test can be accomplished using a "numeric limit" step, as opposed to "pass/fail" test? 

David J.

[Mac671]

This has been an interesting discussion. Although ... in every programming language, or programming environemnt you need to understand the constraints you work with. Compilers / Interpreters are getting better at reading our intentions out of context but sometimes the expectations of how smart they should be is too much :-).

Message Edited by Mac671 on 08-19-2009 04:02 AM