5

We have numerical code written in C++. Rarely but under certain specific inputs, some of the computations result in an 'nan' value.

Is there a standard or recommended method by which we can stop and alert the user when a certain numerical calculation results in an 'nan' being generated? (under debug mode).Checking for each result if it is equal to 'nan' seems impractical given the huge sizes of matrices and vectors.

How do standard numerical libraries handle this situation? Could you throw some light on this?

hAcKnRoCk
  • 1,118
  • 3
  • 16
  • 30

4 Answers4

1

NaN is propagated, when applied to a numeric operation. So, it is enough to check the final result for being a NaN. As for, how to do it -- if building for >= C++11, there is std::isnan, as Goz noticed. For < C++11 - if want to be bulletproof - I would personally do bit-checking (especially, if there may be an optimization involved). The pattern for NaN is 

         ?  11.......1  xx.......x
sign bit ^  ^exponent^  ^fraction^

where ? may be anything, and at least one x must be 1.

For platform dependent solution, there seams to be yet another possibility. There is the function feenableexcept in glibc (probably with the signal function and the compiler option -fnon-call-exceptions), which turns on a generation of the SIGFPE sinals, when an invalid floating point operation occure. And the function _control87 (probably with the _set_se_translator function and compiler option /EHa), which allows pretty much the same in VC.

Number47
  • 493
  • 4
  • 14
  • 1
    In fact, it is this propogation that makes it harder. What if you want to locate where it occured first in a lets say 1000 lines of code, split over classes (obviously sharing computed values between them). You get the situation? I was wondering if anyone else faced this issue and if yes, how they handle it. – hAcKnRoCk May 16 '13 at 16:00
  • @MhAcKNI, so, sadly, you have to rely upon a platform dependent solution. As Stephen Canon mentioned, there is no universal interface. Or at least, I am not aware of it. If you target Windows or Unix, try the above. – Number47 May 16 '13 at 20:35
1

Although this is a nonstandard extension originally from glibc, on many systems you can use the feenableexcept routine declared in <fenv.h> to request that the machine trap particular floating-point exceptions and deliver SIGFPE to your process. You can use fedisableexcept to mask trapping, and fegetexcept to query the set of exceptions that are unmasked. By default they are all masked.

On older BSD systems without these routines, you can use fpsetmask and fpgetmask from <ieeefp.h> instead, but the world seems to be converging on the glibc API.

Warning: glibc currently has a bug whereby (the C99 standard routine) fegetenv has the unintended side effect of masking all exception traps on x86, so you have to call fesetenv to restore them afterward. (Shows you how heavily anyone relies on this stuff...)

Edmund Wells
  • 51
  • 1
0

On many architectures, you can unmask the invalid exception, which will cause an interrupt when a NaN would ordinarily be generated by a computation such as 0*infinity. Running in the debugger, you will break on this interrupt and can examine the computation that led to that point. Outside of a debugger, you can install a trap handler to log information about the state of the computation that produced the invalid operation.

On x86, for example, you would clear the Invalid Operation Mask bit in FPCR (bit 0) and MXCSR (bit 7) to enable trapping for invalid operations from x87 and SSE operations, respectively.

Some individual platforms provide a means to write to these control registers from C, but there's no portable interface that works cross-platform.

Stephen Canon
  • 103,815
  • 19
  • 183
  • 269
-1

Testing f!=f might give problems using g++ with -ffast-math optimization enabled: Checking if a double (or float) is NaN in C++

The only foolproof way is to check the bitpattern.

As to where to implement the checks, this is really dependent on the specifics of your calculation and how frequent Nan errors are i.e. performance penalty of continuing tainted calculations versus checking at certain stages.

Community
  • 1
  • 1
OOhay
  • 61
  • 6