[vtk-developers] More on infinity and NaN in VTK

Tue May 24 11:22:19 EDT 2011

I don't remember the history behind vtkMathConfigure.in, but I'm sure it
comes from some experimentation on the set of compilers VTK supports.
Perhaps there is a better way to discover whether the numeric limits are
available, but there is that old adage "If it ain't broke..."

To try to answer part of your original question (I'm not the definitive
source on this), VTK does not officially support non-finite.  With the
exception of those rudimentary query functions, VTK components are not
guaranteed to handle non-finites correctly.  No one has gone through (what
I am told is) a sizable task to make sure all components and algorithms
behave "correctly" (whatever that might mean).

As far as the FPE signal, I believe that the VTK tests intentionally turn
on whatever signals are available.  The point is to detect when an
algorithm makes an obvious mathematical error like a divide by zero.  Of
course, if you also want to support non-finites, such a signal could
interfere with desired behavior.  This is one of the complexities of
supporting non-finites in VTK.

-Ken

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********  
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

On 5/23/11 6:22 PM, "Philippe Pébay" <pppebay at sandia.gov> wrote:

>Ken,
>
>Thanks for the answer. Yes, I agree, in fact I did not mean to change
>anything vtkMath.cxx, but was wondering whether I
>was missing something else.
>
>Rather if something had to be changed (notice the conditional here!) I
>would venture to say that it would be
>vtkMathConfigure, not vtkMath. I am wondering whether there could be a
>way to detect precisely what is available rather
>than assuming it, the way it is currently done in vtkMathConfigure.in
>
>A related question regards how FPE signal (8) is going to be raised, or
>not, when a division by 0 occurs. On some
>platforms it is not the case (such as, for instance, my version (4.4.4)
>of g++ with FC12), and on some others (such as
>Debian4-unknow-compiler on the Dashboard) it is the case. This results in
>varying outcomes for the test harness, even
>for cases which we could treat in a uniform, predictable way
>(specifically, a degenerate covariance matrix which yet has
>at least one non-singular eigenvalue).
>
>So, my main goal at this point is to try to understand some underlying
>assumptions of the code has it exists today with
>respect to floating point exceptions and numeric limits, and not to
>recommend any change. Sorry if I gave a different
>impression with my earlier message.
>
>Philippe
>
>
>On 05/23/2011 03:14 PM, Moreland, Kenneth wrote:
>> This looks like defensive programming to me.  It's dangerous to assume
>> that VTK_HAS_STD_NUMERIC_LIMITS == !__BORLANDC__.  It could also be that
>> the implementation for neither case was for some other older compiler
>>that
>> is no longer supported.  In either case, I would leave the code how it
>>is.
>>   You could replace the "return vtkMathNanBits.d" with something like
>> "#error Can't figure out NaN for current compiler", but I would
>>definitely
>> leave the third condition there.
>>
>> -Ken
>>
>>     ****      Kenneth Moreland
>>      ***      Sandia National Laboratories
>> ***********
>> *** *** ***  email: kmorel at sandia.gov
>> **  ***  **  phone: (505) 844-8919
>>      ***      web:   http://www.cs.unm.edu/~kmorel
>>
>>
>>
>>
>> On 5/23/11 5:59 PM, "Philippe Pébay"<pppebay at sandia.gov>  wrote:
>>
>>> Hello,
>>>
>>> Following the message which I posted last week (no response so far)
>>> regarding infinity and NaN in VTK, I looked a bit
>>> deeper into the issue and noticed the following apparent contradiction:
>>>
>>> 1. In vtkMathConfigure.in we have the following:
>>>
>>> // We pretty much assume that all compilers are going to provide
>>> // std::numeric_limits methods in the limits header.  On of the Borland
>>> // dashboard compilers failed to link in the methods, so we have a
>>>special
>>> // case here.  If we find more platforms that do not support it
>>>correctly,
>>> // then we should probably implement a TRY_COMPILE in the
>>>CMakeLists.txt.
>>> #ifndef __BORLANDC__
>>> # define VTK_HAS_STD_NUMERIC_LIMITS
>>> #endif
>>>
>>> which means that for all platforms save Borland, we will assume that
>>> numeric_limits are present.
>>>
>>> 2. However, in vtkMath.cxx we have for Nan() (and something similar for
>>> Inf()):
>>>
>>> double vtkMath::Nan()
>>> {
>>> #if defined(VTK_HAS_STD_NUMERIC_LIMITS)
>>>    return vtkstd::numeric_limits<double>::quiet_NaN();
>>> #elif defined(__BORLANDC__)
>>>    return *reinterpret_cast<double*>(&vtkMathNanBits);
>>> #else
>>>    return vtkMathNanBits.d;
>>> #endif
>>> }
>>>
>>> with the effect that the first if statement is rendered useless by the
>>> definitions in vtkMathConfigure.
>>>
>>> Is this done on purpose? Am I missing something else in the picture?
>>>
>>> Thanks
>>> Philippe
>>>
>>>
>>> On 05/23/2011 02:18 PM, Brad King wrote:
>>>> On Mon, May 23, 2011 at 4:13 PM, Philippe Pébay<pppebay at sandia.gov>
>>>> wrote:
>>>>> If you have a few minutes, I would like to discuss the issue of
>>>>> infinity and NaN in VTK.
>>>>
>>>> The most I've ever done with that type of thing is investigate the
>>>> portability of isnan and isinf tests, but that was probably 5 years
>>>> ago.  Hopefully someone will respond on the vtk or titan lists.
>>>> Otherwise I suggest proposing a more specific plan.
>>>>
>>>> -Brad
>>>>
>>>
>>>
>>> --
>>> Philippe Pébay
>>> Sandia National Laboratories
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>
>>
>
>
>-- 
>Philippe Pébay
>Sandia National Laboratories
>