From owner-freebsd-numerics@FreeBSD.ORG Sun Aug 12 23:12:58 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 29AD4106564A for ; Sun, 12 Aug 2012 23:12:58 +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 8A0628FC12 for ; Sun, 12 Aug 2012 23:12:57 +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 q7CNCvtc075938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Aug 2012 09:12:57 +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 q7CNCp7p021856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Aug 2012 09:12:51 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7CNCpIV021855 for freebsd-numerics@freebsd.org; Mon, 13 Aug 2012 09:12:51 +1000 (EST) (envelope-from peter) Resent-From: Peter Jeremy Resent-Date: Mon, 13 Aug 2012 09:12:51 +1000 Resent-Message-ID: <20120812231251.GW20453@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 q6L2S8fk062956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 21 Jul 2012 12:28:08 +1000 (EST) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6L2S456095277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Jul 2012 12:28:06 +1000 (EST) (envelope-from stephen@missouri.edu) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q6L2RfBp095071; Fri, 20 Jul 2012 21:27:42 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <500A139D.2090803@missouri.edu> From: Stephen Montgomery-Smith Mail-Followup-To: freebsd-numerics@freebsd.org User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Bruce Evans References: <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> <20120718205625.GA409@troutmask.apl.washington.edu> <500725F2.7060603@missouri.edu> <20120719025345.GA1376@troutmask.apl.washington.edu> <50077987.1080307@missouri.edu> <20120719032706.GA1558@troutmask.apl.washington.edu> <5007826D.7060806@missouri.edu> <5007AD41.9070000@missouri.edu> <20120719205347.T2601@besplex.bde.org> <50084322.7020401@missouri.edu> <20120720035001.W4053@besplex.bde.org> <50085441.4090305@missouri.edu> <20120720162953.N2162@besplex.bde.org> <20120720184114.B2790@besplex.bde.org> <50097128.6030405@missouri.edu> <20120721032448.X5744@besplex.bde.org> <500A0DCF.4030707@missouri.edu> In-Reply-To: <500A0DCF.4030707@missouri.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Diane Bruce , John Baldwin , David Chisnall , Bruce Evans , Steve Kargl , 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:12:58 -0000 X-Original-Date: Fri, 20 Jul 2012 21:27:41 -0500 X-List-Received-Date: Sun, 12 Aug 2012 23:12:58 -0000 On 07/20/2012 09:02 PM, Stephen Montgomery-Smith wrote: > Hey guys, I just found this paper: > > Implementing complex elementary functions using exception handling, > T. E. Hull, Thomas F. Fairgrieve, Ping-Tak Peter Tang > ACM Transactions on Mathematical Software, Volume 20 Issue 2, June 1994 > Pages 215-244 > > http://dl.acm.org/citation.cfm?doid=178365.178404 > > This includes an algorithm for clog. Now that I have discovered just > how hard it really is, I am going to read this paper. > > There is also a Corrigenda to this paper - the digital copy seems to be > missing. But I will try to retrieve the paper copy from my library. > > http://toms.acm.org/cgi/TOMSbibget.cgi?Anonymous:1994:C > > If anyone else wants a copy of these papers, I would be glad to share > it. But I am using the University of Missouri subscription to ACM, and > I don't want to abuse it by sharing the paper willy-nilly. Ugh. The way they handle the real part of clog(z), log(hypot(x,y)), when hypot(x,y) is close to 1, is to do the calculation in double precision. So to do it properly, we need a double double precision arithmetic, which we don't have. They say it can be simulated, and I think I have seen quad-precision packages (I think it might even be included in FreeBSD ports). But I am not so sure if we want to introduce quad precision into base FreeBSD. The paper says that simulating double precision arithmetic using single arithmetic is slow, so I would think the same is true for quad-precision. Another thing - all their algorithms use exception handling. That is, you go through the steps of the calculation, and if the FPU gives an overflow or underflow error, the program catches it, and then it does something else special. So I guess the programs would have to save the state of the SIGFPE signal, set its own handler, and then restore the SIGFPE signal at the end. And then the program has to keep track of SIGFPE signals it really wanted to send outside of itself, and then trigger those. Does the inexact flag also raise the SIGFPE signal? I can see how to avoid using exception handling, and they mention this in their papers, but they say it isn't clean.