Date: Sun, 28 Dec 2014 22:04:43 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Pedro Giffuni <pfg@freebsd.org> Cc: freebsd-standards@freebsd.org Subject: Re: Does posix say anything about the sign in NaNs ? Message-ID: <20141228214201.V1073@besplex.bde.org> In-Reply-To: <549C7516.5070204@FreeBSD.org> References: <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org> <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org> <2A81225A-09C3-4DFF-A4DA-6B440AFFB857@bsdimp.com> <549C7516.5070204@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 25 Dec 2014, Pedro Giffuni wrote: > On 12/25/14 14:35, Warner Losh wrote: >>> On Dec 25, 2014, at 7:53 AM, Pedro Giffuni <pfg@freebsd.org> wrote: >>>> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans <brde@optusnet.com.au> >>>> ha scritto: >>>> ... >>>> 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. The sign is for debugging, but not very useful without all the NaN bits. >>> 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. > Well, you should only get a NaN when you did something wrong in your > calculation > and that's pretty much the end of it. No, it is valid to generate NaNs intentionally (in C99 with Annex F). Then yo need to debug them. > 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 Interesting. The application parsed "nan", but couldn't handle "-nan". This is an application bug. Any valid inport should be accepted, and that includes "-nan" and also "NAN" and other variations ending in "-nan(n-char-sequence)" if you are producing the output using C. But it is not very useful to generate I think the application used a simple text parser. awk(1) accepts "nan(any)" + 0, as a NaN, but it has a buggy parser since it also accepts "nanany(any)" + 0 as a NaN. Parsing C output using C input routines hopefully works more correctly. > 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. Good. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141228214201.V1073>