Date: Thu, 25 Dec 2014 12:35:27 -0700 From: Warner Losh <imp@bsdimp.com> To: Pedro Giffuni <pfg@freebsd.org> Cc: freebsd-standards@freebsd.org Subject: Re: Does posix say anything about the sign in NaNs ? Message-ID: <2A81225A-09C3-4DFF-A4DA-6B440AFFB857@bsdimp.com> In-Reply-To: <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org> References: <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org> <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] > 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUnGcAAAoJEGwc0Sh9sBEAqFIP/R5A7n+RmWNgOOb5SLpdOvN6 zUBZaIQeDCakL6cblVH9Uea9MmyjnRjka1Z/IZAnuhJFZwTK3cJOauUI103DdT57 qDCqwZi27FVlQbcjk5hzBAyE8lvdw79xd2VyyUv6wP9PyU9ZMuY89OHCWy9WeKvT R98jDJ1zvZzREIEI2nVhYmlrNZAuehLpU+h44mP1Ob5vWZOt5ASojFyfSPZWgDqJ SVgkiAxKWoGTQhjqr57RTGsmGpKXp8YV5B2AhI0sI+DWhHBblp7+N/6XmWBZZa4D fjTmeixsfagdFa2n8PhBhMBW4EtG5UtfU/oU1M0Mmvz816WDibfblFRBYPAUAScV RNkPU1lT4Z4RLUf+7E3KOxXZWYQWLtxnAU5sjSGxW7FQ9xlxvU7+wKjCIIslvieM gyLpz4mKlflWqpmbu5f4mV7EXXPr7R7USGtoxoa+f9YjI04rWreQ4PNwl763IFeL U3ghktFjJUG8luMEEemYM2uaTOUxS0MfWlbrkO3VoFUdFsgO04DkI+Oxl1gnlDP0 A2a9HnTb2npCZc9ndlHa7nb96jjUVlVz90GeXFmgSNPE8F0q3KPnYnOzxRwE9aKF f0e38gep0BlDv4l/byxhYNDXCIo3vGcAhgH2W1uOxjmDI8TQ2J8FYc07KfMIBQTl 81ZHzSVhu48ifuoOa0Fp =C5kF -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A81225A-09C3-4DFF-A4DA-6B440AFFB857>