Date: Thu, 25 Dec 2014 15:35:34 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-standards@freebsd.org Subject: Re: Does posix say anything about the sign in NaNs ? Message-ID: <549C7516.5070204@FreeBSD.org> In-Reply-To: <2A81225A-09C3-4DFF-A4DA-6B440AFFB857@bsdimp.com> References: <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org> <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org> <2A81225A-09C3-4DFF-A4DA-6B440AFFB857@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/25/14 14:35, Warner Losh wrote: >> On Dec 25, 2014, at 7:53 AM, Pedro Giffuni <pfg@freebsd.org> wrote: >> >> Hello; >> >>> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans <brde@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?549C7516.5070204>