(j3.2006) Signaling NaN

[Bill Long]

On 3/11/11 4:19 PM, Fred J. Tydeman wrote:
> These comments are based upon:
>    ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.
>
> 14.11.37 IEEE_VALUE #8 has:
>    Whenever IEEE_VALUE returns a signaling NaN, it is processor
>    dependent whether or not invalid is raised and processor dependent
>    whether or not the signaling NaN is converted into a quiet NaN.
>
> To me, that allows four different behaviours, but only two of them
> make sense:
>    -- return a signaling NaN without invalid raised

This is the intended behavior.  The statement X = IEEE_VALUE(X, 
class_name) is supposed assign to X a value of class class_name. 
Signaling NaN is one of the defined class names.

>    -- return a quiet NaN with invalid raised

The "processor dependent" verbiage was added because there was one 
combination of processor hardware and calling convention that made the 
intended behavior difficult to implement, but this second behavior easy. 
   One could argue that the problem hardware is increasingly archaic, 
and one hopes this problem is not reintroduced into a new processor.  It 
would seem reasonable to consider removing the paragraph you quoted in 
the next revision of the standard.

>
> C99 only supports quiet NaNs (we had too many issues and too little
> payoff trying to do signaling NaNs then).
>

I believe there have been proposals to get rid of signaling NaN's 
entirely (at the IEEE level).


>
> 10.7.2.3.2 F editing #5 has:
>    An input field ...
>    * an optional sign, followed by the string 'NAN', optionally
>      followed by zero or more alphanumeric characters enclosed in
>      parentheses.
>
> Printed page 461 in A.2 has: optional non-blank characters.
> I believe that non-blank needs to be changed to alphanumeric.
>

[461:36-37] refers to "non-blank characters" (for input), which is 
inconsistent with [252:23-24], as you note.  This should be an editorial 
fix for the next revision. (The text in Annex A is not normative, but is 
supposed to match the corresponding text in the normative part of the 
standard.)

[461:39-40] says "alphanumeric characters".  (for output) (Batting 500).


> 10.7.2.3.2 F editing #8 has:
>    For an internal value that is an IEEE NaN, the output field
>    ... followed by the letters 'NaN' and optionally followed by
>    ... alphanumeric processor-dependent characters enclosed in
>    parentheses, ...
>
> C99 also allows lower case letters, upper case letters, digits, and
> underscore inside the parentheses.


 From section 3.1.1 paragraph 2:

The letters, digits, underscore, and special characters make up the 
Fortran character set. Together, the set of letters, digits, and 
underscore define the syntax class alphanumeric-character.

So, it appears Fortran and C99 allow exactly the same subset of 
characters here.


>
>
> We are considering for C three ways to do I/O of signaling NaN:
>    SNAN  == would be invalid input to existing implementation
>    NANS  == would be quiet nan with "S" as next unread character to
>             existing implementation
>    NAN(S == might conflict with existing practice, but least affect on
>             real world.
> The first two have the optional '(alphanumeric chars)'.  The third requires it.
>
> The first two would not be compatible with Fortran.
> The last could be compatible with Fortran.
> Correct?
>

Partly.

The SNAN form is described in the IEEE standard, so this seems 
reasonable for C1x to consider.  This is not currently supported by Fortran.

The form NANS could be confusing.    If it is interpreted as the input 
field is NAN for a floating point input list variable, and the S is part 
of the subsequent field, then this is possible with Fortran if you 
specify a (correctly formed) format for the read statement.

The NAN(chars) form is allowed for Fortran, though there is no 
specification of what chars value might indicate a signaling NaN, if 
any.  The first letter of chars being S does not necessarily imply a 
signaling NaN:

"The NaN value is a quiet NaN if the only nonblank characters in the 
field are ?NAN? or ?NAN()?; otherwise, the NaN value is processor 
dependent."

So this is "compatible" in the sense of not causing an error, but is not 
compatible in the sense of the same value being assigned to the input 
variable.

Cheers,
Bill


> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (775) 358-9748      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101