Fw: Useless sNaNs... or useful?

[Ian McIntosh <ianm@xxxxxxxxxx>]

Despite their imperfect portability and C99 leaving the behaviour of Signaling NaNs undefined, some real users do use them to solve real problems.

The main imperfect portability amounts to whether the upper payload bit is 0=quiet / 1 = signaling or 1=quiet / 0=signaling or some other technique is used. Each has advantages and neither side can change, but that doesn't make them unusable. In about half a dozen lines in one include file you can define payloadless QNAN and SNAN macros for whatever system you're running on.

One important use is to initialize all floating point variables to signaling NaNs. If they are inadvertently not properly initialized later, you will be told if the program attempts to use them. I used to use a pre-754 system that had an option to initialize everything to their equivalent of a negative signaling NaN with the payload containing that particular memory address and a few other bits to make it likely to fail if used as a pointer or subscript. That found bugs even in some carefully written programs that "worked" on other systems (just not correctly). I know of companies doing this themselves today. It would be a worthwhile feature in every system, and doesn't depend much on NaN portability. It is affected by the second imperfect portability - whether the payload is or is not preserved.

If you want isnan ( ) to be able to answer the question for both Quiet or Signaling NaNs, then in most architectures you must transfer the argument to a general purpose register (doing that can be expensive), extract the exponent, see if it's an infinity or NaN, and if yes extract the fraction and see which (zero -> infinity, nonzero -> NaN). Some architectures (including IBM's zSeries and for DFP IBM's pSeries) have special instructions to classify values that allow shorter faster code.

Comparing a value to itself
if (! (x == x) ) then it's a NaN
or if (x != x) then it's a NaN
normally works IF you know all NaNs are quiet. Comparing a Quiet NaN to itself produces unordered not equal. The problem is that comparing a Signaling NaN will usually terminate the program. That's a valid outcome of undefined behaviour, but not one that all users want. Allowing it under a compiler option is a reasonable compromise.

Another complication with that transformation is that some non-754 compliant systems round some values down when they're used or copied or stored, so
x = y+0; if (x != y) then maybe it's a NaN or maybe x just got rounded down and y didn't
can be the surprise. It's especially surprising and hard to explain to an annoyed and sceptical programmer when it happens for "x = y;".

- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development

----- Forwarded by Ian McIntosh/Toronto/IBM on 10/15/2010 01:47 PM -----

From:	Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	10/15/2010 10:22 AM
Subject:	Useless sNaNs...

---

> Date: Fri, 15 Oct 2010 15:43:16 +0200
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Question on performance
> 
> On 2010-10-15 06:37:54 -0400, Michel Hack wrote:
> > Vincent Lef?vre a ?crit:
> > > ...  It's strange that GCC doesn't replace isnan() by a test x != x
> > 
> > Perhaps because these are NOT equivalent?
> 
> I think they are on conforming code.
> 
> > They differ for SNaN.
> 
> sNaN is undefined behavior in ISO C99:
> 
>   F.2.1 Infinities, signed zeros, and NaNs
> 
>   This specification does not define the behavior of signaling NaNs.
> 
> So, the transformation is OK.
> 
> -- 
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>

		 Yes, this is how the C people had to
		 deal with the ambiguity we were forced
		 to leave in 754 WRT NaN behavior.

		 Within broad limits, pretty much any
		 behavior is permitted.

		 It is one of the reasons NaNs are
		 effectively useless for expanding the
		 behavior of the number system in any
		 meaningful & reproducible way.

		 One major distinction between standards
		 & mathematics is that you often have to
		 make compromises to have a standard.


		 		 		 Dan