From owner-freebsd-numerics@FreeBSD.ORG Tue Aug 14 16:51:27 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 25BFA1065680 for ; Tue, 14 Aug 2012 16:51:27 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id EA62B8FC14 for ; Tue, 14 Aug 2012 16:51:26 +0000 (UTC) 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 q7EGpOvR030708; Tue, 14 Aug 2012 11:51:24 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <502A820C.6060804@missouri.edu> Date: Tue, 14 Aug 2012 11:51:24 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Bruce Evans 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> <50295887.2010608@missouri.edu> <20120814055931.Q4897@besplex.bde.org> <50297468.20902@missouri.edu> <20120814173931.V934@besplex.bde.org> In-Reply-To: <20120814173931.V934@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 14 Aug 2012 16:51:27 -0000 On 08/14/2012 05:09 AM, Bruce Evans wrote: > On Mon, 13 Aug 2012, Stephen Montgomery-Smith wrote: > >> But also, what about the problem of when the input is close to one of >> the non-trivial roots of sin, cos, etc? As a mathematician, I >> wouldn't be shocked if sin(M_PI) was 1e-15 or such like. > > M_PI is a rational approximation to pi, so it would be a serious error of > sin() on it were zero. I see your point. But anyone who uses M_PI in their code certainly intends for it to represent Pi, not its rational approximation in double arithmetic. But ... > sin(pi) is an easy case. More intesting is > sin((double)(DBL_MAX/pi) * pi), getting this to work is more of an intellectual exercise than anything useful. (Also it wasn't clear to me whether in this case pi represents real pi or its rational approximation.) When x is incredibly large (close to DBL_MAX), a mathematician would consider x to represent all the numbers between x-x*DBL_EPSILON to x+x*DBL_EPSILON (approximately), or more precisely, all the numbers that are within 0.5 ULP of x. So as a Mathematician I would prefer to think of sin(close_to_DBL_MAX) as undefined. (Although as a programmer, I would hate it if it spat out NaN - I would prefer the meaningless answer.) On the other hand, getting sin(x) correct when x is close to, say, 10pi would be useful. It would be nice if sin(x+0.01)-sin(x) is approximately 0.01*cos(x), and if the computation (x mod pi/2) didn't take into account a few extra digits of pi, and can see this failing for certain values of x. > I already avoid sign errors for NaNs in many places including > hypot*() and atan2*(). This is probably needed for clog() to > pass my tests: I see code like "if (y!=y) return (y+y)". Does "y+y" quieten the NaNs as well as "y+0.0"? Is my code compliant in this regard? > It is bad style to re-use a variable. It micro-optimizes for 30 year > old compilers. It makes the code harder to writem read and debug. > Modern compilers will automatically reuse register and stack resources > for variables if this is possible and doesn't interfere too much with > debugging. That makes sense. > Not reusing variables seems to give slightly better object > code more often than slightly worse object code, by simplifying the > lifetime analysis needed for this optimization. That surprises me a bit. (Although now that I think about it, letting the compiler make the decision seems the better thing to do.) > I only try re-using > variables near the start of a function (maybe x = creal(z); use(x); > x = fabs(x)), to try to stop the compiler making so many copies of x. > This somtimes works. (The typical pessimization avoided by this is > when x passed on the stack. gcc likes to copy it to another place > on the stack, using pessimal methods, and then never use the original > copy. This is good for debugging, but otherwise not very good.). What do you mean by "pessimization"?