#4615 carg range is not in (-%pi, %pi]

[Barton Willis]

The user-documentation for carg says

Function: carg (z)

Returns the complex argument of z. The complex argument is an angle theta in (-%pi, %pi] such that r exp (theta %i) = z where r is the magnitude of z.

In rtest15 there is the test

(c:3(cos(5%pi/13)+%isin(5%pi/13)),
d:4(cos(7%pi/13)+%isin(7%pi/13)),
carg(cd),
trigreduce(%%));
12%pi/13;

/ examples from SF bug #4208: "Error with complex numbers - example with trigreduce" /

trigreduce(carg(c/d));
24*%pi/13;

But 24*%pi/13 is not in (-%pi, %pi]. So I say this is a bug--actually, I think it's a bug in atan2.

[Barton Willis]

Correction: The test is (the formating eliminated the* for multiplication:

(c:3*(cos(5*%pi/13)+%i*sin(5*%pi/13)),
 d:4*(cos(7*%pi/13)+%i*sin(7*%pi/13)),
 carg(c*d),
 trigreduce(%%));
12*%pi/13;

/* examples from SF bug #4208: "Error with complex numbers - example with trigreduce" */

trigreduce(carg(c/d));
24*%pi/13;``

[Raymond Toy]

Haven't looked at the fine details, but it looks like this is coming from absarg in the clause that tests for mtimes. c/d is, of course, represented internally as c*(d^(-1)). It looks like that bit of code just takes the absarg of each element of the list and sums them.

[Barton Willis]

Thanks--I also notice that

(%i2) c:3(cos(5%pi/13)+%isin(5%pi/13));
(c) 3(%isin((5%pi)/13)+cos((5%pi)/13))
(%i3) d:4(cos(7%pi/13)+%isin(7%pi/13));
(d) 4(%isin((7%pi)/13)+cos((7%pi)/13))
(%i4) trace(?simp-%atan2);
(%o4) [simp\-%atan2]
(%i5) carg(c/d);
1" Call "simp\-%atan2[atan2(sin((5%pi)/13),cos((5%pi)/13)),1,true]

1" Return "simp\-%atan2atan(sin((5%pi)/13)/cos((5%pi)/13))

1" Call "simp\-%atan2[atan2(sin((7%pi)/13),cos((7%pi)/13)),1,true]

1" Return "simp\-%atan2atan(sin((7%pi)/13)/cos((7%pi)/13))+%pi

1" Call "simp\-%atan2[atan2(sin((7%pi)/13)/(cos((7%pi)/13)sqrt(sin((7%pi)/13)^2/cos((7%pi)/13)^2+1)),-(1/sqrt(sin((7%pi)/13)^2/cos((7*%pi)/13)^2+1))),1,true]

1" Return "simp\-%atan2-atan(sin((7%pi)/13)/cos((7%pi)/13))-%pi

(%o5) -atan(sin((7%pi)/13)/cos((7%pi)/13))+atan(sin((5%pi)/13)/cos((5%pi)/13))+%pi

I have good evidence that that if atan2 would correctly catch the case atan2(sin(X),cos(X)), we could fix this bug. Actually, I have a bit of code that catches the eight cases

atan2((+/-) sin(X),(+/-)cos(X))
atan2((+/-) cos(X),(+/-)sin(X))

that fixes this bug. But maybe absarg needs to be fixed up too. I think this is a new bug in 5.48.1, but I don't know what changed.

[Barton Willis]

Also, the source code comment for 2pistrip says that it ``Attempts to reduce to interval (-pi,pi]." It often fails in this effort:

(%i8)   ?2pistrip(42);
(%o8)   42

(%i13)  ?2pistrip(42+ 3*%pi);
(%o13)  %pi+42

The source code comment doesn't say what the function is supposed to do when it cannot reduce to the interval (-pi,pi].

[Stavros Macrakis]

2pistrip as written (in 197x) was intended to be strictly syntactic, and to operate with minimal consing, and certainly without calling $floor, which in general uses bfloats via pretty-good-floor-or-ceiling. Time and space were precious. So this isn't a bug (operates as designed), but probably a misfeature.

That said, the trig simplifiers don't handle many cases of %pi reduction either:

sin(%pi*67/5) => unchanged (could be -sin(2/5*%pi))
sin(10) => unchanged 
sin(10+%pi/5) => unchanged

The first case is actually handled better by 2pistrip.
But... is sin(10-2*%pi) or -sin(10-3*%pi) "simpler" than sin(10)?

[Barton Willis]

Fixed by Commit [d00e00] . Regression tests added to rtest_atan2. Closing ticket.