After ?invtrig:
For real arguments x, y, the two-argument function arctan(y, x), computes the principal value of the argument of the complex number x+I*y, so -Pi < arctan(y, x) <= Pi.
For any point in C or R^2 (x,y)<>(0,0) the geometrical meaning of this result is clear: the angle that the segment/vector from (0,0) to (x,y) forms with the x-axis. But this angle is undefined if this point is the origin.
So, what is arctan(0,0)?, and what it should be?
The output of Maple is 0. This value is not documented in ?invtrig, or elsewhere, apparently. So, is this an intended, undocumented value? Is this value a bug?
I read in this Wikipedia article:
As defined above, and traditionally, atan2(0,0) is undefined. Some current implementations define it as 0.
Reasons why I consider that the current output is wrong and should be "undefined" (or an error):
1. The geometrical interpretation stated above, for x,y real.
2. The extension for complex arguments stated in ?invtrig:
This function is extended to complex arguments by the formula
Here I write it as this function (note the order of the arguments):
at:=(x,y)->-I*ln((x+I*y)/sqrt(x^2+y^2));
Presumably this statment means that arctan(y,x)-at(x,y) is identically 0 on C^2, including the origin. This fact is not plain clear as:
f:=(x,y)->arctan(y,x)-at(x,y);
simplify(f(x,y));
x + y I
arctan(y, x) + ln(------------) I
2 2 1/2
(x + y )
But some hint that it is true is given by:
MultiSeries:-series(f(x,y),x=0);
0
Now, Maple produces an error for this "extended" function:
at(0,0); Error, (in at) numeric exception: division by zero
3. What other CAS with equivalent commands produce as output:
Maxima 5.14:
atan2(0,0); atan2(0,0) has been generated. -- an error. To debug this try debugmode(true);
Mathematica 5:
ArcTan[0, 0]
ArcTan::indet: Indeterminate expression tan^(-1)(0, 0) encountered.
Interval[{-\[Pi], \[Pi]}]
Comments
Special case, can be caught
Hi Alejandro,
when you call arctan(0,0), Maple toggles the NumericStatus(invalid_operation) flag from false to true, so you can catch this special case. The ?arctan help page should hint at this feature, I think.
strange implementation
Hi Richard
Thank you for this hint. I find that this "flag" stuff is a quite strange implementation. I read in ?NumericStatus:
So, at interacting level, the execution of this statement produces no message, while the state of the system may change in a hidden way, and you do not know about this change unless you had the "inspiration" to execute NumericStatus() immediately before and immediately after the execution of this statement (as some other statements in the session may also change this flag).
Yes, I see it as an undocumented and not well implemented "feature".
More hints
Well, my posting was probably too short. ;-)
What I meant was: you can let Maple handle such events in almost any way you like. E.g. with
NumericEventHandler(invalid_operation=exception):
arctan(0,0) will raise an error. Or you could supply your own handler procedure instead of 'exception' in the above command. That proc could emit a warning and/or return any special value you prefer.
Admittedly, this is a bit unintuitive at first, but also very flexible.
Excellent hint
But very bad design. I wonder why this is not set by default. And where is the list of operations affected by this setting. More than unintuitive, it is inconsistent that, by default an error is issued here:
while for arctan(0,0), which is basically a "0/0" operation, the default output is 0.