(j3.2006) Signaling NaN

[Robert Corbett]

On 3/11/2011 10:44 AM, Bill Long wrote:
>
>
> On 3/11/11 11:45 AM, Tobias Burnus wrote:
>> On 03/11/2011 06:19 PM, Bill Long wrote:
>>> The standard does specify some of this, and other parts are "processor
>>> dependent".
>>
>> Well, I think it specifies the general format: A NaN is printed. And as
>> one can deduce from the input format, a signalling NaN, if printed as
>> such, has the format "NaN(" + some non-zero-sized string + ")". (Though,
>> the reverse does not work: If there are alphanumeric letters between the
>> "()", it can still be a quiet NaN.)
>>
>>> Note that the standard (inconsistently) requires that on INPUT, the
>>> text is expected to be "NAN"
>>
>> No, it does not: "A lower-case letter is equivalent to the corresponding
>> upper-case letter in an IEEE exceptional specification or the exponent
>> in a numeric input field."
>
>
> Quite right.  I'll have our output form fixed.  (I'd also suggest that 
> the input form in the standard be written as "NaN", which is equally 
> valid as "NAN", but less confusing.
>
I think that will move your implementation out of conformance.  The 
standard says
to write 'NAN' or 'NAN()'.  The permission granted on input is not 
granted for output.
The same restriction applies to exponent letters.  The standard says 
they are upper
case on output, but that they may be upper or lower case on input.  I 
know of one
implementation that finessed the issue by claiming that upper case was 
lower case
and vice versa.  That implementation's implementation of ACHAR was not 
consistent
with that claim.
>
> I would add that the IEEE standard (754-2008) has several paragraphs 
> in 5.12.1 that spell out conversion of NaN values to and from 
> character string representations.  The Fortran rules seem to be 
> consistent with the IEEE rules.
>
They are not.

Bob Corbett