title: Usefulness of signaling NaN?
body: <p>I've recently read up quite a bit on IEEE 754 and the x87 architecture.  I was thinking of using NaN as a "missing value" in some numeric calculation code I'm working on, and I was hoping that using <em>signaling</em> NaN would allow me to catch a floating point exception in the cases where I don't want to proceed with "missing values."  Conversely, I would use <em>quiet</em> NaN to allow the "missing value" to propagate through a computation.  However, signaling NaNs don't work as I thought they would based on the (very limited) documentation that exists on them.</p>
  
  <p>Here is a summary of what I know (all of this using x87 and VC++):</p>
  
  <ul>
  <li>_EM_INVALID (the IEEE "invalid" exception) controls the behavior of the x87 when encountering NaNs</li>
  <li>If _EM_INVALID is masked (the exception is disabled), no exception is generated and operations can return quiet NaN.  An operation involving signaling NaN will <strong>not</strong> cause an exception to be thrown, but will be converted to quiet NaN.</li>
  <li>If _EM_INVALID is unmasked (exception enabled), an invalid operation (e.g., sqrt(-1)) causes an invalid exception to be thrown.</li>
  <li>The x87 <strong>never</strong> generates signaling NaN.</li>
  <li>If _EM_INVALID is unmasked, <strong>any</strong> use of a signaling NaN (even initializing a variable with it) causes an invalid exception to be thrown.</li>
  </ul>
  
  <p>The Standard Library provides a way to access the NaN values:</p>
  
  <pre><code>std::numeric_limits&lt;double&gt;::signaling_NaN();
  </code></pre>
  
  <p>and</p>
  
  <pre><code>std::numeric_limits&lt;double&gt;::quiet_NaN();
  </code></pre>
  
  <p>The problem is that I see no use whatsoever for the signaling NaN.  If _EM_INVALID is masked it behaves exactly the same as quiet NaN.  Since no NaN is comparable to any other NaN, there is no logical difference.</p>
  
  <p>If _EM_INVALID is <em>not</em> masked (exception is enabled), then one cannot even initialize a variable with a signaling NaN:
  <code>double dVal = std::numeric_limits&lt;double&gt;::signaling_NaN();</code> because this throws an exception (the signaling NaN value is loaded into an x87 register to store it to the memory address).</p>
  
  <p>You may think the following as I did:</p>
  
  <ol>
  <li>Mask _EM_INVALID.</li>
  <li>Initialize the variable with signaling NaN.</li>
  <li>Unmask_EM_INVALID.</li>
  </ol>
  
  <p>However, step 2 causes the signaling NaN to be converted to a quiet NaN, so subsequent uses of it will <strong>not</strong> cause exceptions to be thrown!  So WTF?!</p>
  
  <p>Is there any utility or purpose whatsoever to a signaling NaN?  I understand one of the original intents was to initialize memory with it so that use of an unitialized floating point value could be caught.</p>
  
  <p>Can someone tell me if I am missing something here?</p>
  
  <hr>
  
  <p><strong>EDIT:</strong></p>
  
  <p>To further illustrate what I had hoped to do, here is an example:</p>
  
  <p>Consider performing mathematical operations on a vector of data (doubles).  For some operations, I want to allow the vector to contain a "missing value" (pretend this corresponds to a spreadsheet column, for example, in which some of the cells do not have a value, but their existence is significant).  For some operations, I do <em>not</em> want to allow the vector to contain a "missing value."  Perhaps I want to take a different course of action if a "missing value" is present in the set -- perhaps performing a different operation (thus this is not an invalid state to be in).</p>
  
  <p>This original code would look something like this:</p>
  
  <pre><code>const double MISSING_VALUE = 1.3579246e123;
  using std::vector;
  
  vector&lt;double&gt; missingAllowed(1000000, MISSING_VALUE);
  vector&lt;double&gt; missingNotAllowed(1000000, MISSING_VALUE);
  
  // ... populate missingAllowed and missingNotAllowed with (user) data...
  
  for (vector&lt;double&gt;::iterator it = missingAllowed.begin(); it != missingAllowed.end(); ++it) {
      if (*it != MISSING_VALUE) *it = sqrt(*it); // sqrt() could be any operation
  }
  
  for (vector&lt;double&gt;::iterator it = missingNotAllowed.begin(); it != missingNotAllowed.end(); ++it) {
      if (*it != MISSING_VALUE) *it = sqrt(*it);
      else *it = 0;
  }
  </code></pre>
  
  <p>Note that the check for the "missing value" must be performed <strong>every loop iteration</strong>.  While I understand in most cases, the <code>sqrt</code> function (or any other mathematical operation) will likely overshadow this check, there are cases where the operation is minimal (perhaps just an addition) and the check is costly.  Not to mention the fact that the "missing value" takes a legal input value out of play and could cause bugs if a calculation legitimately arrives at that value (unlikely though it may be).  Also to be technically correct, the user input data should be checked against that value and an appropriate course of action should be taken.  I find this solution inelegant and less-than-optimal performance-wise.  This is performance-critical code, and we definitely do not have the luxury of parallel data structures or data element objects of some sort.</p>
  
  <p>The NaN version would look like this:</p>
  
  <pre><code>using std::vector;
  
  vector&lt;double&gt; missingAllowed(1000000, std::numeric_limits&lt;double&gt;::quiet_NaN());
  vector&lt;double&gt; missingNotAllowed(1000000, std::numeric_limits&lt;double&gt;::signaling_NaN());
  
  // ... populate missingAllowed and missingNotAllowed with (user) data...
  
  for (vector&lt;double&gt;::iterator it = missingAllowed.begin(); it != missingAllowed.end(); ++it) {
      *it = sqrt(*it); // if *it == QNaN then sqrt(*it) == QNaN
  }
  
  for (vector&lt;double&gt;::iterator it = missingNotAllowed.begin(); it != missingNotAllowed.end(); ++it) {
      try {
          *it = sqrt(*it);
      } catch (FPInvalidException&amp;) { // assuming _seh_translator set up
          *it = 0;
      }
  }
  </code></pre>
  
  <p>Now the explicit check is eliminated and performance should be improved.  I think this would all work if I could initialize the vector without touching the FPU registers...</p>
  
  <p>Furthermore, I would imagine any self-respecting <code>sqrt</code> implementation checks for NaN and returns NaN immediately.</p>