From owner-freebsd-numerics@FreeBSD.ORG Sun Aug 12 23:13:57 2012 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C3131065673 for ; Sun, 12 Aug 2012 23:13:57 +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 9C8E58FC14 for ; Sun, 12 Aug 2012 23:13:56 +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 q7CNDuRC075987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Aug 2012 09:13:56 +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 q7CNDo4c021964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Aug 2012 09:13:50 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7CNDoKE021963 for freebsd-numerics@freebsd.org; Mon, 13 Aug 2012 09:13:50 +1000 (EST) (envelope-from peter) Resent-From: Peter Jeremy Resent-Date: Mon, 13 Aug 2012 09:13:49 +1000 Resent-Message-ID: <20120812231349.GG20453@server.rulingia.com> Resent-To: freebsd-numerics@freebsd.org Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6K2KMM7023903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Jul 2012 12:20:23 +1000 (EST) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6K2KNfl085049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Jul 2012 12:20:23 +1000 (EST) (envelope-from brde@optusnet.com.au) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6K2JwWw023391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2012 12:19:59 +1000 From: Bruce Evans Mail-Followup-To: freebsd-numerics@freebsd.org X-X-Sender: bde@besplex.bde.org To: Stephen Montgomery-Smith In-Reply-To: <50083E83.9090404@missouri.edu> Message-ID: <20120720120802.F1061@besplex.bde.org> References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> <20120713155805.GC81965@zim.MIT.EDU> <20120714120432.GA70706@server.rulingia.com> <20120717084457.U3890@besplex.bde.org> <5004A5C7.1040405@missouri.edu> <5004DEA9.1050001@missouri.edu> <20120717200931.U6624@besplex.bde.org> <5006D13D.2080702@missouri.edu> <20120719144432.N1596@besplex.bde.org> <50083E83.9090404@missouri.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 12 Aug 2012 23:56:00 +0000 Cc: Diane Bruce , Steve Kargl , John Baldwin , David Chisnall , Bruce Evans , Bruce Evans , David Schultz , Peter Jeremy , 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:13:57 -0000 X-Original-Date: Fri, 20 Jul 2012 12:19:58 +1000 (EST) X-List-Received-Date: Sun, 12 Aug 2012 23:13:57 -0000 On Thu, 19 Jul 2012, Stephen Montgomery-Smith wrote: > On 07/19/2012 01:37 AM, Bruce Evans wrote: >> ... >> problem. Complex functions should have only poles and zeros, with >> projective infinity and "projective zero" (= inverse of projective >> infinity). Real functions can and do have affine infinities and zeros >> (+-Inf and +-0), with more detailed special cases. It's just impossible >> to have useful, detailed special cases for all the ways of approaching >> complex (projective) infinity and 0. >> ... >> sign functions). Hopefully, the specification of imag(clog()) is >> that it has the same sign behaviour as atan2(), so you can just use >> atan2(). The sign conventions for both are arbitrary, but they >> shouldn't be gratuitously different. You still have to check that >> they aren't non-gratuitously different, because different conventions >> became established. > > I checked. Actually the sign conventions are not that arbitrary. But as a > mathematician I would say they are a bit useless, e.g. > atan(infinity,infinity) = pi/4 = 45 degrees > How do you know that the two infinities are the same? One could be double > the other. It should be NaN with projective infinity. > If it had been up to me, there would have been finite numbers, and nan. And > none of this -0. I think Kahan is a mathematician, and is primarily responsible for +-0. +-0 give poor man's branch cuts for real functions. >> I don't know what happens with zeros of complex inverse trig functions. >> I think they don't have many (like log()), but their real and imaginary >> parts do, and they are too general for accurate behaviour of the real >> and imaginary parts relative to themselves to fall out. > > casinh(z) is zero only when z=0, and near that point I could use Taylor's > series (but a lot of terms would be needed because the Taylot series > converges quite slowly). To get accuracy near zeros, you only need to use a series method in a very small radius. Even a linear approximation may be enough, and the main difficulty is the linear term: f() ~= f'(z0) * (z-z0) where z0 typically needs to be known to hundreds or thousands of bits of precision and the subtraction must be done in this precision. f'(z0) and the multiplkication only need a couple of extra bits. This is only easy when z0 is a dyadic rational. > I can now see that the separate cases of the real part and imaginary parts of > casinh being zero is going to be hard. I won't ask for that and will measure errors relative to the absolute value of the result. Bruce