[Insight-developers] Failing test vnl_test_math
Luis Ibanez
luis.ibanez at kitware.com
Mon Apr 20 11:37:13 EDT 2009
On Thu, Apr 16, 2009 at 6:43 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> Bill,
>
> More on this.
>
> The error message would indicate that the problem is in
>
> > !isinf(qnan_q) - **FAILED**
>
> that corresponds to line 183 of
>
> Insight/Utilities/vxl/core/vnl/tests/test_math.cxx
>
> which is
>
> testlib_test_assert("!isinf(qnan_q) ", !vnl_math_isinf(qnan_q));
>
>
> however,
> when isolating this line in the following example:
>
>
> #include "vcl_limits.h"
> #include "vnl/vnl_math.h"
> #include <iostream>
>
> int main()
> {
> long double qnan_q = vcl_numeric_limits<long double>::quiet_NaN();
> bool result1 = !vnl_math_isfinite(qnan_q);
> bool result2 = !vnl_math_isinf(qnan_q);
>
> std::cout << "Finite = " << result1 << std::endl;
> std::cout << "Infinte = " << result2 << std::endl;
>
> return 0;
> }
>
>
> It produces the following output in Linux gcc 4.2
>
> Finite = 1
> Infinte = 1
>
> and the following output in Sun-CC
>
>
> Finite = 1
> Infinte = 0
>
>
> For the record.
>
> This tests started failing in April 5 when we were amidst the
> frenzy of changes related to -stlport4. It didn't look important
> at the time when we had hundreds of compilation errors.
>
>
> It is tempting to speculate that the method used by VXL for
> implementing isinf() for long doubles is not valid when the
> flag -stlport4 is used with the Sun-CC compiler.
>
>
>
> Luis
>
>
>
> ----------------------------------------------------------------------------
> On Thu, Apr 16, 2009 at 6:13 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>> Hi Bill,
>>
>> I just logged in dashsun1
>>
>> and here is the full test print out:
>>
>> -------------------------------------------------------------
>>
>> Test command: /home/kitware/Dashboards/MyTests/Insight-CC/bin/vnl_test_all
>> test_math
>> -----------------------------------------------------------------------------
>> Start Testing test_math:
>> -----------------------------------------------------------------------------
>> n = -11
>> f = -7.5
>> d = -3.14159
>> i = (0,1)
>> z = (-1,2)
>> exp(d*i) = (-1,-1.22465e-16)
>>
>> abs(n) = 11
>> abs(f) = 7.5
>> abs(d) = 3.14159
>> abs(i) = 1
>> abs(z) = 2.23607
>> norm(z) = 5
>>
>> abs(n) == 11 - PASSED
>> abs(f) == 7.5 - PASSED
>> abs(d) == pi - PASSED
>> abs(i) == 1 - PASSED
>> abs(-1+2i)~=sqrt(5) should be 2.23607, is 2.23607, PASSED
>> norm(-1+2i) ~= 5 should be 5, is 5, PASSED
>> exp(d*i) ~= -1 should be 0, is 1.22465e-16, PASSED
>>
>> rnd(-8.4999) == -8 - PASSED
>> rnd(-8.4999f) == -8 - PASSED
>> vnl_math_rnd(-8.50) == -9
>> rnd(-8.50) == -8/9 - PASSED
>> rnd(-8.50f) == -8/9 - PASSED
>> vnl_math_rnd(-8.5001) == -9
>> rnd(-8.5001) == -9 - PASSED
>> rnd(-8.5001f) == -9 - PASSED
>> rnd(8.4999) == 8 - PASSED
>> rnd(8.4999f) == 8 - PASSED
>> rnd(8.50) == 8/9 - PASSED
>> vnl_math_rnd(8.50) == 9
>> rnd(8.50f) == 8/9 - PASSED
>> vnl_math_rnd(8.5001) == 9
>> rnd(8.5001) == 9 - PASSED
>> rnd(8.5001f) == 9 - PASSED
>> isfinite(f) - PASSED
>> isfinite(d) - PASSED
>> isfinite(i) - PASSED
>> isfinite(z) - PASSED
>> vcl_numeric_limits<float>::has_infinity==true assumption - PASSED
>> vcl_numeric_limits<double>::has_infinity==true assumption - PASSED
>> vcl_numeric_limits<ldouble>::has_infinity==true assumption - PASSED
>> vcl_numeric_limits<float>::has_quiet_NaN==true assumption - PASSED
>> vcl_numeric_limits<double>::has_quiet_NaN==true assumption - PASSED
>> vcl_numeric_limits<ldouble>::has_quiet_NaN==true assumption - PASSED
>> pinf_f = inf = �ninf_d = -inf = ��!isfinite(qnan_d) - PASSED
>> !isinf(qnan_d) - PASSED
>> isnan(qnan_d) - PASSED
>> !isfinite(pinf_q) - PASSED
>> !isfinite(ninf_q) - PASSED
>> isinf(pinf_q) - PASSED
>> isinf(ninf_q) - PASSED
>> !isnan(pinf_q) - PASSED
>> !isnan(ninf_q) - PASSED
>> !isfinite(qnan_q) - PASSED
>> !isinf(qnan_q) - **FAILED**
>> !isfinite(huge_val(double)) - PASSED
>> !isfinite(huge_val(float)) - PASSED
>> -----------------------------------------------------------------------------
>> test_math Test Summary: 56 tests succeeded, 1 test failed *****
>> -----------------------------------------------------------------------------
>> -- Process completed
>>
>>
>> -----
>>
>>
>> I'm taking a look at the code...
>>
>>
>> Luis
>>
>> ------------------------------------------------------------------------------------------
>> On Thu, Apr 16, 2009 at 3:01 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>> Luis,
>>>
>>> Looks like there is only 1 failing test left (at least today):
>>> http://www.cdash.org/CDash/testDetails.php?test=20138903&build=313966
>>>
>>> Notice that the output is truncated, so we can't see what part of the
>>> test is failing. Actually, it is truncated even on systems where it
>>> passes (e.g. http://www.cdash.org/CDash/testDetails.php?test=2017929&build=313981
>>> )
>>>
>>> Also, the same test on the vxl dashboard is also truncated, forthe
>>> same reason I believe:
>>> http://www.cdash.org/CDash/testDetails.php?test=16499304&build=313792
>>>
>>>
>>> The test uses an internal macro, print_hex that attempts to print the
>>> hex digits of inf, nan, etc. They can't be printed with std::hex since
>>> they have special meaning and printing a inf just prints "inf". The
>>> print_hex macro casts the output one digit at a time to unsigned char.
>>> We know from ITK that this is not a good idea, and that the
>>> "PrintType" should be something that is printable (e.g. unsigned int).
>>>
>>> Someone (a vxl person) should look at this problem. As a temporary
>>> measure we could disable the print_hex portion of the code so that we
>>> can see where the SUN build is failing.
>>>
>>> Interesting to note that the only failing test and only valgrind
>>> defects are in the vxl code that we use.
>>>
>>> Bill
>>>
>>
>
------------------------------------------------
Bill,
More findings on the vnl_math test failure in Sun-CC.
1) long double in this platform
(machine + compiler + compilation options )
has sizeof = 16 bytes.
2) qnan_q in this platform is assigned a value:
(dbx) x qnan_q = E
0x7FF10000 0x00000000 0x00000000 0x00000000 +7.26154477146748e+4927
However the code in:
Insight/Utilities/vxl/core/vnl/vnl_math.cxx
lines: 218 and 285 are comparing against the pattern:
0x7FF70000L
Note the change from "7FF7" to "7FF1"
I'm tracking the exact location
where the comparison takes place....
3) From a quick Google Search, it seems that the
the proper value for NAN in "long double" is:
7FF7 FFFF FFFF FFFF
(for an HP...)..
but I'm not finding a clear definition.
The 7FF1 seems to be for:
"Addition of opposite signed infinities 7FF10000 00000000"
So....
It is not clear if the problem is that SunCC is generating an
improper quiet NAN or whether we are comparing against
the wrong pattern in that platform.
Any suggestions and/or words of wisdom will be appreciated.
I'll keep tracking this....
Luis
More information about the Insight-developers
mailing list