From owner-freebsd-numerics@FreeBSD.ORG Sun Jul 29 23:53:12 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 2D279106564A for ; Sun, 29 Jul 2012 23:53:12 +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 CD4988FC0C for ; Sun, 29 Jul 2012 23:53:11 +0000 (UTC) Received: from server.rulingia.com (c220-239-247-45.belrs5.nsw.optusnet.com.au [220.239.247.45]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6TNr9FF080672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Jul 2012 09:53:09 +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 q6TNr3Yl077823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jul 2012 09:53:03 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6TNr2uV077818 for freebsd-numerics@FreeBSD.org; Mon, 30 Jul 2012 09:53:02 +1000 (EST) (envelope-from peter) Date: Mon, 30 Jul 2012 09:53:02 +1000 From: Peter Jeremy To: freebsd-numerics@FreeBSD.org Message-ID: <20120729235302.GA77192@server.rulingia.com> References: <500DAD41.5030104@missouri.edu> <20120724113214.G934@besplex.bde.org> <501204AD.30605@missouri.edu> <20120727032611.GB25690@server.rulingia.com> <20120728125824.GA26553@server.rulingia.com> <501460BB.30806@missouri.edu> <20120728231300.GA20741@server.rulingia.com> <50148F02.4020104@missouri.edu> <20120729222706.GA29048@server.rulingia.com> <5015BB9F.90807@missouri.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <5015BB9F.90807@missouri.edu> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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: , X-List-Received-Date: Sun, 29 Jul 2012 23:53:12 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Pruning CC list to keep mailman happy]] On 2012-Jul-29 17:39:27 -0500, Stephen Montgomery-Smith wrote: >On 07/29/2012 05:27 PM, Peter Jeremy wrote: >> WG14/N1256 G.6. I hadn't considered extending that to verifying that >> purely real or imaginary inputs give purely real or imaginary outputs, >> with the appropriately signed zero. This might be reasonable but it's >> not completely trivial to implement in general since the domains of >> the real part can be different. > >Maybe this should be a different program, since its logical structure=20 >would be quite different. In particular, you wouldn't be checking the=20 >value of the non-zero parts. Adding code to skip checks on the real or imaginary part of the result is quite easy. >Also I forgot that the real part of casinh(0+I*x) isn't always 0. If=20 >|x|>1, it is something non-zero. And so you need to check that=20 >creal(casinh(0+I*x)) and creal(casinh(-0+I*x)) have opposite signs in=20 >this case. This is related to my "domains can be different" comment. Adding code to restrict the domain of the argument to be compatible with the real function isn't too hard (off the top of my head, I think the domains are all one of [-1,1], [0,Inf] or (0,Inf]). Handling behaviour outside that domain requires more special-casing because the behaviour is less consistent. >> I'm less sure of the next logical >> step, which is to check things like >> casinh(x + I*0) =3D asinh(x) + I*0 > >Does C99 mandate this? Nope. They are just mathematical equivalences (at least within the domains supported by the real function). POLA implies that they should be true but unless they are special-cased, the complex variant probably has less accuracy as a result of the additional calculations to support the imaginary component. > My programs probably won't satisfy this, because=20 >I realized that the computation works in these cases anyway. Of course,= =20 >it would be easy to make it happen. It's probably up to the implementation - special casing pure real or imaginary arguments should give those cases a shorter and simpler (and therefore faster and more accurate) calculation but it's a matter of whether this case in common enough to justify the additional test(s) in all cases. It's also just occurred to me that doing so may result in unexpected output discontinuities between cfoo(x-I*tiny), cfoo(x-I*0), cfoo(x+I*0) and cfoo(x+I*tiny). --=20 Peter Jeremy --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAVzN4ACgkQ/opHv/APuIe5UwCdF6wpQAi6u98WpyPu8PlZDdQZ iqMAn2R5qrF3jIKUiL+P9RkSc73ShnIQ =yZ7u -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi--