Date: Sun, 12 Aug 2012 23:00:18 -0000 From: Peter Jeremy <peter@rulingia.com> To: Bruce Evans <brde@optusnet.com.au> Cc: Diane Bruce <db@db.net>, John Baldwin <jhb@freebsd.org>, David Chisnall <theraven@freebsd.org>, Stephen Montgomery-Smith <stephen@missouri.edu>, Bruce Evans <bde@freebsd.org>, Steve Kargl <sgk@troutmask.apl.washington.edu>, David Schultz <das@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: Use of C99 extra long double math functions after r236148 Message-ID: <20120721003103.GA73662@server.rulingia.com> Resent-Message-ID: <20120812230011.GR20453@server.rulingia.com> In-Reply-To: <20120718123627.D1575@besplex.bde.org> References: <20120717084457.U3890@besplex.bde.org> <5004A5C7.1040405@missouri.edu> <5004DEA9.1050001@missouri.edu> <20120717040118.GA86840@troutmask.apl.washington.edu> <20120717042125.GF66913@server.rulingia.com> <20120717043848.GB87001@troutmask.apl.washington.edu> <20120717225328.GA86902@server.rulingia.com> <20120717232740.GA95026@troutmask.apl.washington.edu> <20120718001337.GA87817@server.rulingia.com> <20120718123627.D1575@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Bruce or das@ or Steve, I have a question on the following code from s_ccosh.c: % /* % * cosh(NaN + I NaN) =3D d(NaN) + I d(NaN). % * % * cosh(NaN +- I Inf) =3D d(NaN) + I d(NaN). % * Optionally raises the invalid floating-point exception. % * Choice =3D raise. % * % * cosh(NaN + I y) =3D d(NaN) + I d(NaN). % * Optionally raises the invalid floating-point exception for fini= te % * nonzero y. Choice =3D don't raise (except for signaling NaNs). % */ % return (cpack((x * x) * (y - y), (x + x) * (y - y))); x is always NaN so the real part presumably just needs to be quietened before returning - ie (x + x) would seem to be sufficient. Why does the code use ((x * x) * (y - y))? y has no restriction on its value so an arithmetic operation with x is a good way to convert it to a NaN. Wouldn't (y + x) be sufficient? My understanding is that: - Addition is generally faster than multiplication - Signs are irrelevant for NaN so merging the sign of x doesn't matter. - NaN + NaN returns the (quietened?) left-hand NaN - Inf + NaN returns the (quietened?) right-hand NaN - finite + NaN returns the (quietened?) right-hand NaN Also, whilst things like ((x + x) * (y - y)) are reasonably efficient on x86, few (if any) RISC architectures support exceptional conditions in hardware. My understanding is that SPARC would trap back into the userland handler (lib/libc/sparc64/fpu) on each operation unless both arguments and the result are normalised numbers. Explicitly fiddling with the FPU state would seem faster than multiple traps. --=20 Peter Jeremy --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAJ+EcACgkQ/opHv/APuIdyMwCfZAIdShOhLfYvF85audLwPDXc qv4An0zDk2V7gAxY9LrM1MHccIcgzeo9 =OkzB -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120721003103.GA73662>