From owner-freebsd-bugs@FreeBSD.ORG Fri Jul 27 14:27:05 2012 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 542911065674; Fri, 27 Jul 2012 14:27:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id DF6AD8FC0A; Fri, 27 Jul 2012 14:27:04 +0000 (UTC) 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 mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6REQu72015165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jul 2012 00:26:58 +1000 Date: Sat, 28 Jul 2012 00:26:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Stephen Montgomery-Smith In-Reply-To: <201207270247.q6R2lkeR021134@wilberforce.math.missouri.edu> Message-ID: <20120727233939.A7820@besplex.bde.org> References: <201207270247.q6R2lkeR021134@wilberforce.math.missouri.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/170206: complex arcsinh, log, etc. X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 14:27:05 -0000 On Wed, 25 Jul 2012, Stephen Montgomery-Smith wrote: > This function seems to be able to compute clog with a worst case relative > error of 4 or 5 ULP. > ... I lost your previous reply about this after reading just the first part. Please resend if interested. First part recovered by vidcontrol: VC> > I'm still working on testing and fixing clog. Haven't got near the more VC> > complex functions. VC> > VC> > For clog, the worst case that I've found so far has x^2+y^2-1 ~= 1e-47: VC> > VC> > x = 0.999999999999999555910790149937383830547332763671875000000000 VC> > y = VC> > 0.0000000298023223876953091912775497878893005143652317201485857367516 VC> > (need high precision decimal or these rounded to 53 bits binary) VC> > x^2+y^2-1 = 1.0947644252537633366591637369e-47 VC> VC> That is exactly 2^(-156). So maybe triple quad precision really is enough. Hmm. But you need 53 more value bits after the 156. Quadruple precision gives 3 to spare. I didn't notice that this number was exactly a power of 2, but just added 15-17 for the value bits in decimal to 47 to get over 60. VC> > so it needs more than tripled double precision for a brute force VC> > evaluation, and the general case is probably worse. I'm working VC> > on a rearrangement so that doubled double precision works in the VC> > general case. Both your version and my version get this case right, VC> > but mess up different much easier cases. It takes insanely great VC> > accuracy to get even 1 bit in this case right, but now that we Tripled double precision is enough for this because -1 cancels with leading terms, giving almost quadrupled double precision: % hm1 = -1; % for (i=0;i<12;i++) hm1 += val[i]; % return (cpack(0.5 * log1p(hm1), atan2(y, x))); It is the trailing terms that I think don't work right here. You sort them and add from high to low, but normally it is necessary to add from low to high (consider terms [1, DBL_EPSILON/2, DBL_EPSILON/4]). Adding from high to low cancels with the -1 term, but then only particular values work right. Also, I don't see how adding the low terms without extra precision preserves enough precision. Bruce