NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Comparison to 0 in TS 2012 SP1

Solved!
Go to solution

Concerning bug 346934 (The comparison function can yield different results when operands are swapped if one operand is zero) in http://www.ni.com/white-paper/14361/en/ I would like to report that TS 2012 SP1 yields the wrong result in both cases.

 

That is, when I take a small number and compare !=0, it will yield FALSE, regardless whether it is (0 != SmallNumber) or (SmallNumber != 0). This will prevent us from using TS 2012 SP1 as we need this comparison to work.

 

Attached a sequence that demonstrates it. Run with TS 2012, Test0First will be false, Test0Last will be true; run with TS 2012 SP1, both will be false.

 

Regards

 

Peter

0 Kudos
Message 1 of 12
(5,192 Views)
Solution
Accepted by topic author pwaszkewitz

This was fixed in TestStand 2013, would it be possible for you to upgrade to that version? In case you are curious or need this info later, the id for the fix is

 

Hope this helps,

-Doug

0 Kudos
Message 2 of 12
(5,170 Views)

Hi dug9000

 

good to know. We do not have problems with TS2012 (no SP) in our projects, so that is fine for now.

 

As it is, we will skip TS2013, there is simply too much testing involved, and go straight to TS2014 as this will allow us a full 64-bit environment.

 

Thank you

 

Peter

 

 

0 Kudos
Message 3 of 12
(5,168 Views)

It was also partially fixed in the 2012 sp1 f1 patch (Basically, the original change to 2012 sp1 was reverted so if you install the patch you will get back to the TestStand 2012 behavior), but that still only works if the zero is on the right hand side. It was fully fixed in TestStand 2013.

 

-Doug

0 Kudos
Message 4 of 12
(5,164 Views)

Hi,

we are still seeing the problem in TS 2014, 64- bit version, regardless of the sequence of comparison. Is anything known about this?

Regards

Peter

0 Kudos
Message 5 of 12
(3,399 Views)

Strange - I've run your sequence in TS 2014 SP1 64-bit without any problems.

 

However... Comparing floating point variables for equality are always going to be problematic due to how the values are stored (see the White Paper: Comparing Floating-Point Numbers).

 

Try using the CheckLimits function to see if that functions correctly:

 

Locals.Test0CheckLimits = (CheckLimits(Locals.TestNumber, 0, 0, "NE") == "Passed")

 

 

I've attached an updated version of your test sequence.

 

I hope this helps,

Charlie Rodway | Principal Software Engineer | Certified TestStand Architect (CTA)

Computer Controlled Solutions Ltd | NI Silver Alliance Partner | GDevCon#1 Sponsor

0 Kudos
Message 6 of 12
(3,395 Views)

Thanks a lot, will test this.

I am aware of the problem checking floating point numbers for equality. The point is that these numbers are actually 64-bit pointers. We will switch to using the 64-bit unsigned int interpretation as soon as possible, but currently we are working with a COM interface to a 64-bit server which was written for an earlier TS version where this interpretation did not exist. Therefore, the interface expects a 64-bit numerical value as a double.

Regards, Peter

0 Kudos
Message 7 of 12
(3,391 Views)

Just want to make sure you are aware of the following:

 

Storing 64-bit integers as doubles can lead to incorrect values for higher numbers and should thus be avoided. doubles cannot store the full 64-bit integer range of values.

 

Or are you perhaps doing a re-interpret cast and storing the raw data of the integer in the memory for the double? If so then it would not be valid to interpret or do comparisons with that value on the TestStand side.

 

-Doug

Message 8 of 12
(3,381 Views)

 

Hello, and happy New Year.

 

I have some questions that might help narrow this down:

 

  1. Is the failure you are seeing the actual original test case attached above, or some other floating point case?  (I tried the original test case on a more recent version of TestStand that I have handy and did not see the issue.)
  2. Does your current issue happen with 32-bit TestStand 2014 as well as 64-bit?  (There are differences in how 32-bit and 64-bit TestStand 2014 handle floating point numbers.)
  3. Did your old case (with TestStand 2012) use a 64-bit COM server or a 32-bit server?  (Storing a 32-bit pointer in 64-bit double, while inelegant, will work just fine.  As Doug already noted, storing a 64-bit integer in a double is going to have more problems unless you are super careful.)
  4. Do you have top-down addressesing enabled on your system?  (I cannot find a really good link, but this Microsoft KB talks about the relevant registry key.  Top-down addressing is controlled by the registry key as discussed in the "More Information" section.)

Thanks and best regards,

 

-Jed

 

 

Message 9 of 12
(3,361 Views)

Yes, we are basically interested in the bit pattern.

It would be a bit long-winded to explain how this came about, historically, but we will in the future change our DLL so that we can use the new 64-bit-unsigned interpretation of TestStand.

Thank you for the information that a comparison will not be valid in this case.

Peter

0 Kudos
Message 10 of 12
(3,310 Views)