From owner-freebsd-numerics@FreeBSD.ORG Wed Aug 15 22:34:25 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 E8947106564A for ; Wed, 15 Aug 2012 22:34:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 795B28FC08 for ; Wed, 15 Aug 2012 22:34:25 +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 mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q7FMYL5l026171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2012 08:34:23 +1000 Date: Thu, 16 Aug 2012 08:34:21 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Stephen Montgomery-Smith In-Reply-To: <502C1E89.9070408@missouri.edu> Message-ID: <20120816081911.W3938@besplex.bde.org> References: <5017111E.6060003@missouri.edu> <501C361D.4010807@missouri.edu> <20120804165555.X1231@besplex.bde.org> <501D51D7.1020101@missouri.edu> <20120805030609.R3101@besplex.bde.org> <501D9C36.2040207@missouri.edu> <20120805175106.X3574@besplex.bde.org> <501EC015.3000808@missouri.edu> <20120805191954.GA50379@troutmask.apl.washington.edu> <20120807205725.GA10572@server.rulingia.com> <20120809025220.N4114@besplex.bde.org> <5027F07E.9060409@missouri.edu> <20120814003614.H3692@besplex.bde.org> <50295F5C.6010800@missouri.edu> <20120814072946.S5260@besplex.bde.org> <50297CA5.5010900@missouri.edu> <50297E43.7090309@missouri.edu> <20120814201105.T934@besplex.bde.org> <502C0998.7040004@missouri.edu> <502C194D.50903@missouri.edu> <502C1E89.9070408@missouri.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-numerics@freebsd.org Subject: Re: Complex arg-trig functions 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: Wed, 15 Aug 2012 22:34:26 -0000 I will be away for a couple of weeks. Hope nothing happens :-). On Wed, 15 Aug 2012, Stephen Montgomery-Smith wrote: > On 08/15/2012 04:49 PM, Stephen Montgomery-Smith wrote: >> On 08/15/2012 03:42 PM, Stephen Montgomery-Smith wrote: >>> >>> All your solutions depend upon using (1-tiny) with the result being >>> used. But what if FE_DOWNWARD is set? Then 1-tiny becomes >>> 1-DBL_EPSILON. And then if the result is used, everything is off by 1 >>> ulp. Yes, this is another example that msun depends a lot on the default rounding mode. >>> And >>> if ((int)(1 - tiny) == 1) >>> will fail. But this can be fixed to ((int)(1 + tiny) == 0). I was originally going to use addition, but then grep showed fdlibm mostly using subtraction. At least some uses of (one - tiny) seem to be intentional. E.g., s_tanh.c returns +-(one - tiny) for the asymptotes to value +-1. Although 1 would be more accurate, if the rounding mode is unusual then the caller must actually want the less accurate value that results from not rounding to nearest. (one - tiny) is always <= 1. This is consistent with the asymptote always being < 1. >> How about replacing >> >> if (huge+ax>one && huge+bx>one) .... >> >> with >> >> if ((int)(1/ax)==0 || (int)(1/bx)==0) .... >> >> (We know that one of ax or bx is larger than 1.) > > if ((int)(1/(2+ax))==0) .... > > (because one of ax or bx might be 0). Now it is getting too heavyweight. Although this is not a fast path, a division in it makes it really slow. Bruce