Does posix say anything about the sign in NaNs ?

[Warner Losh]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-standards/attachments/20141225/65611e01/attachment.sig>