Behavior of ArcTan when two zeros are given as arguments

I've noticed that the numeric approximation of ArcTan is a bit different from the symbolic one.

If I write

ArcTan[0,0]


I obtain

ArcTan::indet: "Indeterminate expression ArcTan[0,0] encountered.


While if I write

ArcTan[0.0, 0]


I obtain

0


Instead I expect to obtain also in this case an indeterminate result. Is there some specific reason for this behavior?

=== EDIT ===

J. M. has noticed also this:

ArcTan[0, 0.0]


gives

Pi/2


=== EDIT 2 ===

celtschk also noticed that

ArcTan[0.0, 0.0]


gives

ArcTan::indet: "Indeterminate expression ArcTan[0.,0.] encountered.


but it does generate an output:

Interval[{-Pi, Pi}]


Edit 2015-11-29

I ran into this problem while working with some code in V10.3. I found this question (obviously), but since the V10.3 behavior is different, I thought I should edit the and report that behavior. -- m_goldberg

-
Additional quirk: compare ArcTan[0., 0] and ArcTan[0, 0.]. Hmm... – J. M. Oct 1 '12 at 13:19
Interesting, I didn't notice it... – Jepessen Oct 1 '12 at 13:22
Now we know for sure that rule30 is extensively used – Dr. belisarius Oct 1 '12 at 13:25
@belisarius: Why is that so? I fail to see the immediate link, care to explain? – István Zachar Oct 1 '12 at 14:50
ArcTan[0.0,0.0] again gives ArcTan::indet. – celtschk Oct 1 '12 at 14:53

2 Answers

When you write ArcTan[0,0], you tell Mathematica that the parameters x and y in ArcTan[x,y] are the exact integer 0. As we know, 0/0 cannot be unambiguously defined, and Indeterminate is returned. So ArcTan[0,0] returns the result of Interval[{-Pi,Pi}], for the codomain of ArcTan[0,0] is just between -Pi and Pi.

On the other hand, if you write ArcTan[0.0,0], y is the exact integer 0, but x is approximate real numbers which approaches 0 but not the exact interger 0. Therefore, (exact 0)/(approximate 0) = exact 0, resulting in ArctTan[0.,0] == 0.( Similar for ArcTan[0,0.] == Pi/2)

Now, consider why ArcTan[0.,0.] returns Interval[{-Pi,Pi}], similar to ArcTan[0,0]. For this question, we must first keep it in mind that every approximate real numbers in Mathematica has its finite precision and accuracy. The default precision in Mathematica can be obtained by $MachinePrecision, which is 15.9546. So, in the default setting, the paremeters x and y in ArcTan[0.,0.] have the same precision. Let me draw an analogy: when x and y have the the same precision 10,they can see each other the same effective number of digits, that is, the first 10 numbers of x and y are all 0. As for the 11th number and those after that, Mathematica did not take them into account when calculating, since those numbers are out of the precision and ambiguous. As a result, ArcTan[0.,0.] involves the situation 0/0, returning Indeterminate. Now, let us make a little change-just increase one of parameters (x or y) to the precision 16, such as ArcTan[N[0,16],0.], which returns Pi/2. This is because x=N[0,16] has greater precision than y=0. (which is just 15.9546). So, y with the precision of 15.9546 can only see x the first 15.9546 numbers and think x is 0, while x with precision 16 can see what the y's 16th number is and think y is not 0. Hence, (Not 0)/0 causes Infinity. (Similar to ArcTan[0.,N[0,16]] returning 0) The above analogy may be inexact, but in short, the phenomenon in question is related to the precision of real numbers in Mathematica. If you expect to obtain in the case of ArcTan[0.,0] an indeterminate result, you can use Chop function. ArcTan[Chop[0.],0] returns Indeterminate. Hope this will help you. - It's not exactly "greater precision"; ponder on the outputs of $MachinePrecision == MachinePrecision, ArcTan[N[0, $MachinePrecision], N[0, MachinePrecision]] and ArcTan[N[0, MachinePrecision], N[0,$MachinePrecision]]... – J. M. Nov 21 '12 at 11:12
@J.M. I think your example is because of the…er…strange property of $MachinePrecision, according to the document, $MachinePrecision is numerically Equal to MachinePrecision, but $MachinePrecision uses arbitrary precision computations with machine precision resolution. In fact NumberForm@N[0,$MachinePrecision] is 0, while NumberForm@N[0, MachinePrecision] is 0. – xzczd Nov 21 '12 at 12:54
But the behaviour of ArcTan[0.0, 0.0] is still unresolved, also, why doesn't ArcTan[0, -0.] return -Pi/2? – xzczd Nov 21 '12 at 13:04
@xzczd, ack, I forgot that N[0, stuff] still returns an exact zero if stuff =!= MachinePrecision... – J. M. Nov 21 '12 at 13:05
Well, coming back to this answer after playing with Mathematica for 3 more years, I noticed that I didn't fully understand @J.M. 's comment at that time. Now I'm quite sure this answer is not perfect and has even made several mistakes (e.g. mixing up MachinePrecision and \$MachinePrecision, not noticing N[0, 16] still returns an exact zero rather than an approximate zero with precision 16). Oh, now I can answer the "why doesn't ArcTan[0, -0.] return -Pi/2" question myself, it's because -0. evaluates to 0., which I think is a not-hard-to-accept default behavior. – xzczd Jan 6 at 14:43

I think you get this result because for Mathematica handles 0.0 here as a number which approaches 0.

Define e.g.

f[x_, y_] := ArcTan[y/x]


As for ArcTan[0,0] you get for f[0,0] a not meaningful result (lastly because a point at (0,0) can enclose with the abscissa all angles from [-π,π], therefore also the output Interval[{-π,π}]).

But if you use

 Limit[f[x, 0], x -> 0]


You get as for ArcTan[0.,0] as result 0. The same works if you use the limit for y:

ArcTan[0,0.] and Limit[Limit[f[x,y],x -> 0],y -> 0]give as result π/2.

So, by writing ArcTan[0,0.] you are telling Mathematica that you are approaching the (0,0) on the y-axis and this gives then the same result as e.g. ArcTan[0,10] (similar for ArcTan[0.,0]).

If you use ArcTan[0.,0.] you are approaching (0,0) on both axes to the same time. This is geometrically not possible (the point can only be on both axes to the same time in the origin of the coordinate system; thats why I used two limits above), therefore you get here again as result Interval[{-π,π}].

-
@Nasser M. Abbasi: I corrected the code in my answer so that you have it in the correct form after copying it from here. – partial81 Nov 21 '12 at 9:46
Then why doesn't ArcTan[0.,0.] return Interval[{-π/2,π/2}]? – xzczd Nov 21 '12 at 13:11
I am not sure, perhaps this is mathematicas standard output when the expression is indeterminate? – partial81 Nov 22 '12 at 0:03
{"extraction_info": {"found_math": true, "script_math_tex": 0, "script_math_asciimath": 0, "math_annotations": 0, "math_alttext": 0, "mathml": 0, "mathjax_tag": 0, "mathjax_inline_tex": 1, "mathjax_display_tex": 0, "mathjax_asciimath": 1, "img_math": 0, "codecogs_latex": 0, "wp_latex": 0, "mimetex.cgi": 0, "/images/math/codecogs": 0, "mathtex.cgi": 0, "katex": 0, "math-container": 0, "wp-katex-eq": 0, "align": 0, "equation": 0, "x-ck12": 0, "texerror": 0, "math_score": 0.7140646576881409, "perplexity": 2444.1395288302647}, "config": {"markdown_headings": false, "markdown_code": true, "boilerplate_config": {"ratio_threshold": 0.18, "absolute_threshold": 20, "end_threshold": 15, "enable": false}, "remove_buttons": true, "remove_image_figures": true, "remove_link_clusters": true, "table_config": {"min_rows": 2, "min_cols": 3, "format": "plain"}, "remove_chinese": true, "remove_edit_buttons": true, "extract_latex": true}, "warc_path": "s3://commoncrawl/crawl-data/CC-MAIN-2016-18/segments/1461860121534.33/warc/CC-MAIN-20160428161521-00053-ip-10-239-7-51.ec2.internal.warc.gz"}