From owner-freebsd-numerics@FreeBSD.ORG Sun Aug 12 23:00:18 2012 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 181EB106566B for ; Sun, 12 Aug 2012 23:00:18 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id B25DE8FC18 for ; Sun, 12 Aug 2012 23:00:17 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7CN0HiY075565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Aug 2012 09:00:17 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q7CN0BCn021024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Aug 2012 09:00:11 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7CN0BIM021023 for freebsd-numerics@freebsd.org; Mon, 13 Aug 2012 09:00:11 +1000 (EST) (envelope-from peter) Resent-From: Peter Jeremy Resent-Date: Mon, 13 Aug 2012 09:00:11 +1000 Resent-Message-ID: <20120812230011.GR20453@server.rulingia.com> Resent-To: freebsd-numerics@freebsd.org From: Peter Jeremy Mail-Followup-To: freebsd-numerics@freebsd.org To: Bruce Evans Message-ID: <20120721003103.GA73662@server.rulingia.com> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <20120718123627.D1575@besplex.bde.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Diane Bruce , John Baldwin , David Chisnall , Stephen Montgomery-Smith , Bruce Evans , Steve Kargl , David Schultz , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 12 Aug 2012 23:00:18 -0000 X-Original-Date: Sat, 21 Jul 2012 10:31:03 +1000 X-List-Received-Date: Sun, 12 Aug 2012 23:00:18 -0000 --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--