[GiNaC-list] atan2(0,-4) = -Pi?

[Richard B. Kreckel]

Dear Jan,

Jan Bos wrote:
> Is there a reason for GiNaC (or ginsh) to evaluate 
> atan2(0,-4) as -Pi instead of +Pi the definition used by for instance
> C/C++? Looking at the code, inifcns_trans.cpp last shown case below,
> explicitly states it should. Or can I expect it to be changed in the
> future?
> 
> static ex atan2_eval(const ex & y, const ex & x)
> {
>   if (y.info(info_flags::numeric) && x.info(info_flags::numeric)) {
> 
>     if (y.is_zero()) {
> 
>       // atan(0, 0) -> 0
>       if (x.is_zero())
> 	return _ex0;
> 
>       // atan(0, x), x real and positive -> 0
>       if (x.info(info_flags::positive))
> 	return _ex0;
> 
>       // atan(0, x), x real and negative -> -Pi
>       if (x.info(info_flags::negative))
> 	return _ex_1*Pi;
>     }
> 

I don't suppose anybody lightly intends to change such definitions.  :)

Well, I looked in my notes and didn't find anything motivating that 
choice for atan2.

I recall that back when I wrote this, CLTL 2nd edition provided guidance 
when choosing branch cuts of single-argument functions in the complex 
domain. And later at some point I realized that the C99 standard agrees 
with CLTL for all single-argument functions. (That appeared to be too 
good to be true, but it is true.) Nobody was aware of LIA-3 at that time 
but I'm quite sure that all of GiNaC's single-argument functions agree 
with LIA-3, simply because they agree with C99.

Our two-argument function atan2, however, may never have been checked 
against any standard. I just did that with C99 and CLTL, and they both 
specify atan2(0,-4) to be +Pi, indeed. Maybe, we ought to change this? 
Before we do so: What does LIA-3 say?

Our choice may be bad but I frankly admit that I don't know why +Pi is 
any better than -Pi, or a more symmetric choice a la Mathematica like 
atan2(0,x>0)=Pi/2, atan2(0,x<0)=-Pi/2, or 0 for all x. Can you explain 
that choice?

Cheers
   -richy.

PS: In any case, this is a good lesson how not to write comments, sigh.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>