Bugzilla – Bug 2094
test failure for optimized build in tv-spectrum-transmitter calculations
Last modified: 2015-04-13 00:48:14 UTC
On 32-bit optimized builds with gcc-4.8.3 (Fedora 20) and gcc-4.9.1 (Ubuntu 14.10), the tv-spectrum-transmitter test fails: Details: Message: peak PSD value (220.79) is incorrect Condition: maxValue (actual) < expectedPsd (limit) + TOLERANCE (tol) && maxValue (actual) > expectedPsd (limit) - TOLERANCE (tol) Actual: 220.79 Limit: 220.79 +- 1e-15 File: ../src/spectrum/test/tv-spectrum-transmitter-test.cc Line: 127 I have looked at this and it seems to me to be a spurious failure; if one perturbs the code a little bit around this test, the test passes. The details above suggest that the failure should not have occurred. Lowering the TOLERANCE value to something smaller like (1e-6) also clears the failure. This can be worked around by adding some (logically) no-op statements around the test, but I wonder whether it should be looked into further.
> I have looked at this and it seems to me to be a spurious failure; if one > perturbs the code a little bit around this test, the test passes. The > details above suggest that the failure should not have occurred. Lowering > the TOLERANCE value to something smaller like (1e-6) also clears the failure. > > This can be worked around by adding some (logically) no-op statements around > the test, but I wonder whether it should be looked into further. It occurred to me after writing this that the problem is likely that as the value under test ranges across orders of magnitude in this test, we are most likely exceeding the precision of doubles, testing against a very small fixed TOLERANCE. TOLERANCE should instead increase as the value increases so that the comparison is not in excess of the number of significant digits of precision (and we were getting lucky on other platforms that didn't cause a test failure). I'll work on an appropriate patch.
I decided to use the approach documented here: http://realtimecollisiondetection.net/blog/?p=89 The corresponding patch is found here: http://code.nsnam.org/ns-3-dev/rev/2fad26bb3070