Does posix say anything about the sign in NaNs ?

[Pedro Giffuni]

On 12/25/14 14:35, Warner Losh wrote:
>> On Dec 25, 2014, at 7:53 AM, Pedro Giffuni <pfg at freebsd.org> wrote:
>>
>> Hello;
>>
>>> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans <brde at optusnet.com.au> ha scritto:
>>>
>>> On Wed, 24 Dec 2014, Pedro Giffuni wrote:
>>>
>>>> I got the attached patch from OpenBSD.
>>>>
>>>> It says:
>>>> ____
>>>> Show the sign for NaN as per POSIX; from Elliott Hughes.
>>>> ok martynas@, millert@, doug@
>>>> ____
>>>>
>>>> I can't find a reference in POSIX documentation to support it though.
>>> The behaviour is implementation-defined.  From n869.txt for printf:
>>>
>>> X                A  double  argument  representing  an  infinity   is
>>> X                converted in one of the styles [-]inf or [-]infinity
>>> X                 --   which  style  is  implementation-defined.    A
>>> X                double  argument  representing a NaN is converted in
>>> X                one of the styles [-]nan or [-]nan(n-char-sequence)
>>> X                 --  which style, and the  meaning  of  any  n-char-
>>> X                sequence,    is   implementation-defined.    The   F
>>> X                conversion specifier produces INF, INFINITY, or  NAN
>>> X                instead of inf, infinity, or nan, respectively.220)
>>>
>>> "style" is not clearly defined.  The format for input in strtod()
>>> is formally defined as [-]something without using the term "style",
>>> but the specication for actually handling the minus sign is even less
>>> complete (see below).
>>>
>>> The library intentionally suppresses the sign for NaNs on output.
>>> This is consistent with it ignororing the sign for NaNs on input.
>>>
>>
>> Interesting and pretty much the reason why I wanted to discuss the change.
>>
>> I can see the sign information is important for infinity but indeed it makes
>> very little sense (if any) for NaN. OTOH, we are doing an extra assignment
>> to hide something the standard permits. If we are ignoring the sign of NaNs
>> on input there should be no such sign information in the first place and
>> ignoring the value is unnecessary.
>>
>> While I am tempted to follow the change, I think it is pretty much innocuous
>> as no reasonably correct program should depend on the sign of NaN.
> My only concern with this change is that numeric programs might actually break because they know this implementation detail. Its here some way to discover if things my pysci or R have any change in behavior here? In addition to the standard, numerical methods have much apocrypha associated with them.
>
> Warner

Well, you should only get a NaN when you did something wrong in your 
calculation
and that's pretty much the end of it. Googling around, it appears glibc 
did a similar
change, and it did cause issues to someone:

http://stackoverflow.com/questions/3772835/getting-a-negative-nan-on-g-4-4-3-is-this-standard

Given it's implementation dependent I now think it is better to keep the 
historical
behavior consistent so I won't be committing the change.

Cheers,

Pedro.