Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Aug 2012 11:51:24 -0500
From:      Stephen Montgomery-Smith <stephen@missouri.edu>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        freebsd-numerics@freebsd.org
Subject:   Re: Complex arg-trig functions
Message-ID:  <502A820C.6060804@missouri.edu>
In-Reply-To: <20120814173931.V934@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> <50295887.2010608@missouri.edu> <20120814055931.Q4897@besplex.bde.org> <50297468.20902@missouri.edu> <20120814173931.V934@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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"?





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?502A820C.6060804>