From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
05-22-2014 03:38 AM
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
Solved! Go to Solution.
05-22-2014 11:07 AM
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
05-22-2014 11:10 AM
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
05-22-2014 11:19 AM - edited 05-22-2014 11:20 AM
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
01-03-2017 05:30 AM
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
01-03-2017 06:48 AM
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
01-03-2017 07:36 AM
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
01-03-2017 09:37 AM - edited 01-03-2017 09:43 AM
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
01-03-2017 05:34 PM
Hello, and happy New Year.
I have some questions that might help narrow this down:
Thanks and best regards,
-Jed
01-13-2017 01:51 AM
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