[Insight-developers] Failing test vnl_test_math

Luis Ibanez luis.ibanez at kitware.com
Mon Apr 20 16:03:24 EDT 2009


Done:

http://public.kitware.com/cgi-bin/viewcvs.cgi/Utilities/vxl/core/vnl/tests/test_math.cxx?root=Insight&r1=1.9&r2=1.10&sortby=date


    Luis


-------------------------------------------
On Mon, Apr 20, 2009 at 3:25 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> I think we should bypass that part of the test. It does not affect ITK.
>
> On Mon, Apr 20, 2009 at 3:22 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>> 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