[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-gsl] Uninitialized variables and signaling NaNs

From: Andrew W. Steiner
Subject: [Help-gsl] Uninitialized variables and signaling NaNs
Date: Sun, 8 Aug 2010 13:12:00 -0400

Hello all,

     There was recently a big discussion in the D0 collaboration
at Fermilab about a signaling NaN popping up in uninitialized variables.
To use some GSL code to demonstrate the issue, I've copied
some of cdf/cauchyinv.c from 1.14 below (edited to make it compact).
[I'm not a member of D0 myself and don't have access to their
code.] The issue is that the optimizer is free to load values in the register
if it likes, and in particular it may do so with the variable 'x'.
Unfortunately since x is uninitialized, the value of x is determined
by whatever happens to be in memory, i.e. it might contain
a signaling NaN. In that case, a floating point exception is
triggered and the code crashes. D0 went so far as to contact
a local member of the C++ standards committee to verify this

     Obviously one could turn off floating point exceptions, but
that seems like a bad way to go about things, as it might
prevent you from missing other errors elsewhere.

    Thus I'm inclined to think that this code in GSL below,
and all other code like it should, in principle, be rewritten.
This is quite a bit of work, however, as there are dozens
of files in GSL which are susceptible to this kind of failure.
I'm not suggesting that this needs to be fixed desperately
but I wanted to post to see if anyone else
had seen this problem and had some other brilliant
suggestions. Crowd-sourcing ftw.

Take care,


double gsl_cdf_cauchy_Pinv (const double P, const double a) {
  double x;
  if (P == 1.0) {
      return GSL_POSINF;
    } else if (P == 0.0) {
      return GSL_NEGINF;

  if (P > 0.5) {
      x = a * tan (M_PI * (P - 0.5));
    } else {
      x = -a / tan (M_PI * P);

   // .. etc etc etc

reply via email to

[Prev in Thread] Current Thread [Next in Thread]