# Complex result for real vectors in VectorAngle

Bug introduced in 10.0 or earlier and fixed in 12.0.0 or earlier

I was expecting a real angle using VectorAngle when passing real valued vectors, but I obtained a complex angle:

VectorAngle[{-2.7432000000000016, 0., 0.},{2.743199999999973, 0., 0.}]


returns

3.14159 - 2.10734*10^-8 I


I was expecting 3.14159 ($$\pi$$) as this is essentially a half circle. My guess is the precision of the numbers results in the imaginary portion.

3 possible solutions are:

• using Round[result, 10^-7], which works for this case, but future cases might have an imaginary part larger than $$10^{-8}$$

• using Re[result], a better solution.

Interestingly, using Round on the vectors to some sufficiently small value results in an exact solution. For example I rounded to the nearest 10^-100 and got the exact value of $$\pi$$.

Going forward I'll probably just take the real part of the result, but is this the expected behavior in Mathematica for this function?

I believe this is one of the many manifestations of machine precision arithmetic in Mathematica, and it appears because VectorAngle also works with complex values. If you use the arbitrary precision engine, these cancellation errors should not occur:

 VectorAngle[{-2.743212, 0, 0}, {2.743212, 0, 0}]

3.14159


Note the 12 on the numbers; this sets a precision of 12 digits. Perhaps more applicable to your situation, you can use SetPrecision (or SetAccuracy) on existing data to convert it to arbitrary precision:

in = {{-2.7432000000000016, 0., 0.}, {2.743199999999973, 0., 0.}};

VectorAngle @@ SetPrecision[in, 12]

3.14159


Likewise, using exact arithmetic will avoid this problem as you already note:

VectorAngle @@ Rationalize[in]

π


Please see the second part of this answer for an introduction to machine and arbitrary precision in Mathematica in my own words:

• @Adam You're welcome, and thanks for the Accept. Aug 14, 2014 at 22:22

Just found this. This is probably a good opportunity to demonstrate the importance of using a numerically stable formula.

I will use a simpler example:

p1 = {2.7432, 0., 0.}; p2 = {-2.743199, 0., 0.};


VectorAngle[] surprisingly returns a complex result:

VectorAngle[p1, p2]
3.141592653589793 - 2.1073424338879928*^-8*I


but using the explicit classical formula seems okay:

ArcCos[Normalize[p1].Normalize[Conjugate[p2]]]
3.141592653589793


Now, consider this example:

p1 = {2.7432000016, 0., 0.}; p2 = {-2.743199992, 0., 0.};


VectorAngle[] does fine:

VectorAngle[p1, p2]
3.141592653589793


but the explicit formula becomes inaccurate:

ArcCos[Normalize[p1].Normalize[Conjugate[p2]]]
3.141592638688632


Tricky. Both can be inaccurate for nearly antipodal vectors. What to do?

Fortunately, Velvel Kahan has us covered with a much more numerically reliable formula:

vecang[v1_?VectorQ, v2_?VectorQ] := Module[{n1 = Norm[v1], n2 = Norm[v2]},
2 ArcTan[Norm[v1 n2 + n1 v2], Norm[v1 n2 - n1 v2]]]


which is accurate in both of the cases I gave:

vecang @@@ {{{2.7432, 0., 0.}, {-2.743199, 0., 0.}},
{{2.7432000016, 0., 0.}, {-2.743199992, 0., 0.}}}
{3.141592653589793, 3.141592653589793}


VectorAngle[] now gives accurate results as of version 11.2:

VectorAngle @@@ {{{2.7432, 0., 0.}, {-2.743199, 0., 0.}},
{{2.7432000016, 0., 0.}, {-2.743199992, 0., 0.}}} // InputForm
{3.141592653589793, 3.141592653589793}


I think this is a bug.

You get the correct result from

vectorAngle[vec1_, vec2_] :=
ArcCos[vec1.vec2/(Norm[vec1] Norm[vec2])]

vectorAngle[{-2.7432000000000016, 0.,
0.}, {2.743199999999973, 0., 0.}]

(* ==> 3.14159 *)


This function is just a manual implementation of the definition as stated in the documentation of VectorAngle. Therefore, the current built-in VectorAngle does not appear to be implemented as described in the documentation.

This is to note that at some point, this bug in VectorAngle has been fixed in or before V13.2:

VectorAngle[
{-2.7432000000000016, 0., 0.},
{2.743199999999973, 0., 0.}]
(*  3.14159  *)


The version history in the docs does not indicated that VectorAngle has been changed.

• Nice catch and thanks for updating. I checked that it's fixed from v12.0.0`.
– bmf
Feb 28 at 1:27