[Insight-developers] Failing test vnl_test_math
Luis Ibanez
luis.ibanez at kitware.com
Mon Apr 20 15:22:33 EDT 2009
On Mon, Apr 20, 2009 at 11:37 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> 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
>
----------------------------------------------
Bill,
More on this Sun CC issue.
It seems that it all boils down to the following:
long double qnan_q = vcl_numeric_limits<long double>::quiet_NaN();
bool K = isnan(qnan_q) ;
returns "false" in the Sun CC with -stlport4
(it returns True on Linux)
In this platform, isinf is defined as
bool vnl_math_isinf(long double x)
{
return !finitel(x) && !isnan(x);
}
It seems that "isnan" itself is not well defined across platforms
for "long double":
We have:
Insight/Utilities/vxl/core/vnl/tests/test_math.cxx
line 186-188
#if 0 // even more nonstandard ...
testlib_test_assert(" isnan(qnan_q) ", vnl_math_isnan(qnan_q));
#endif // 0
We could fix vnl_math_isinf() if we could use vnl_math_isnan()...but...
Any suggestions ?
Luis
More information about the Insight-developers
mailing list