Date: Thu, 16 Aug 2012 08:34:21 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Stephen Montgomery-Smith <stephen@missouri.edu> Cc: freebsd-numerics@freebsd.org Subject: Re: Complex arg-trig functions Message-ID: <20120816081911.W3938@besplex.bde.org> In-Reply-To: <502C1E89.9070408@missouri.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120816081911.W3938>