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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_BC4BA5D4-07DC-4C31-88B1-B87C64A07005 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 25, 2014, at 7:53 AM, Pedro Giffuni <pfg@freebsd.org> wrote: >=20 > Hello; >=20 >> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans = <brde@optusnet.com.au> ha scritto: >>=20 >> On Wed, 24 Dec 2014, Pedro Giffuni wrote: >>=20 >>> I got the attached patch from OpenBSD. >>>=20 >>> It says: >>> ____ >>> Show the sign for NaN as per POSIX; from Elliott Hughes. >>> ok martynas@, millert@, doug@ >>> ____ >>>=20 >>> I can't find a reference in POSIX documentation to support it = though. >>=20 >> The behaviour is implementation-defined. =46rom n869.txt for printf: >>=20 >> 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) >>=20 >> "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). >>=20 >> The library intentionally suppresses the sign for NaNs on output. >> This is consistent with it ignororing the sign for NaNs on input. >>=20 >=20 >=20 > Interesting and pretty much the reason why I wanted to discuss the = change. >=20 > 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. >=20 > 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 --Apple-Mail=_BC4BA5D4-07DC-4C31-88B1-B87C64A07005 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----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----- --Apple-Mail=_BC4BA5D4-07DC-4C31-88B1-B87C64A07005--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A81225A-09C3-4DFF-A4DA-6B440AFFB857>