From owner-freebsd-numerics@FreeBSD.ORG Sun Aug 12 23:03:46 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 04537106566B for ; Sun, 12 Aug 2012 23:03:46 +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 6487D8FC17 for ; Sun, 12 Aug 2012 23:03:45 +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 q7CN3j6P075642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Aug 2012 09:03:45 +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 q7CN3ep1021203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Aug 2012 09:03:40 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7CN3eQl021202 for freebsd-numerics@freebsd.org; Mon, 13 Aug 2012 09:03:40 +1000 (EST) (envelope-from peter) Resent-From: Peter Jeremy Resent-Date: Mon, 13 Aug 2012 09:03:40 +1000 Resent-Message-ID: <20120812230340.GJ20453@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 q6RDLe2L034885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Jul 2012 23:21:40 +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 q6RDLcQv043856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jul 2012 23:21:40 +1000 (EST) (envelope-from stephen@missouri.edu) Received: from [128.206.184.213] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q6RDLD1O044993; Fri, 27 Jul 2012 08:21:14 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <501295C9.6080108@missouri.edu> From: Stephen Montgomery-Smith Mail-Followup-To: freebsd-numerics@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans References: <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> <20120722121219.GC73662@server.rulingia.com> <500DAD41.5030104@missouri.edu> <20120724113214.G934@besplex.bde.org> <501204AD.30605@missouri.edu> <20120727032611.GB25690@server.rulingia.com> <20120727155521.E4712@besplex.bde.org> In-Reply-To: <20120727155521.E4712@besplex.bde.org> 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:03:46 -0000 X-Original-Date: Fri, 27 Jul 2012 08:21:13 -0500 X-List-Received-Date: Sun, 12 Aug 2012 23:03:46 -0000 On 07/27/12 02:27, Bruce Evans wrote: > On Fri, 27 Jul 2012, Peter Jeremy wrote: > >> On 2012-Jul-26 22:02:05 -0500, Stephen Montgomery-Smith >> wrote: >>> I am not getting many responses to the programs I submitted. I >>> understand that you may be all very busy. > > I'm still working on testing and fixing clog. Haven't got near the more > complex functions. > > For clog, the worst case that I've found so far has x^2+y^2-1 ~= 1e-47: > > x = 0.999999999999999555910790149937383830547332763671875000000000 > y = > 0.0000000298023223876953091912775497878893005143652317201485857367516 > (need high precision decimal or these rounded to 53 bits binary) > x^2+y^2-1 = 1.0947644252537633366591637369e-47 That is exactly 2^(-156). So maybe triple quad precision really is enough. > > so it needs more than tripled double precision for a brute force > evaluation, and the general case is probably worse. I'm working > on a rearrangement so that doubled double precision works in the > general case. Both your version and my version get this case right, > but mess up different much easier cases. It takes insanely great > accuracy to get even 1 bit in this case right, but now that we > have about 52 of 53 right, the work for getting the final bit > right is essentially the same as proving that the method works > in all cases. That's for x^2+y^2-1. log1p() is much harder. The general case is also the worst for the arc-trig functions. The edge cases seem to be computed with great accuracy. When I tell my friends I get approx 51 bit accuracy, they seem to think it is pretty good. > >> I've been writing a test harness to vet the special case handling of >> all the complex functions (excluding cpow so far). Basically, it's If I remember correctly, the C99 specification is very liberal in its requirements for cpow, so that cpow(x,y) = cexp(y*clog(x)) is compliant. > > I use a my test harness for float and double functions hacked for > complex functions where it doesn't work so well, and hackish pari > extensions. > >> just Appendix G.6 of WG14/N1256 turned into a C array, plus code to >> actually run the tests & interpret the results. So far, it's about >> 1100 lines of which about 1/3 is the test cases and is intended to run > > Yikes. My basic test program is getting too large and complex at 412 > lines. It basically just compares with a known good or different bad > function (with zillions of parameters to select the function and args). > It tests exceptional cases as a side effect. > > Do you do tests for fenv (i.e, that the specified exceptions and no > others are raised)? This might be a problem with external libraries. > The can deliver values and NaNs for comparison, but nothing requires > them to have the same fenv behaviour as the C library. Any tests > of fenv are likely to spew errors that you don't want to know about. Testing the fenv values seems like a really good idea to me.