Cartesian To Spherical Coordinates

Converting Between Coordinate Systems

Cartesian coordinates use three perpendicular axes (x, y, z) to locate a point in space. Spherical coordinates use a distance from the origin (r), an angle from the positive z-axis (theta, often called phi in math textbooks), and an azimuthal angle around the z-axis (phi or theta depending on convention). The conversion is straightforward trigonometry, but the convention mismatch between physics and mathematics causes more headaches than the actual math. Here's the core set of equations if you're using the standard math convention where theta is the polar angle (from the positive z-axis) and phi is the azimuthal angle (in the xy-plane from the positive x-axis): r = sqrt(x² + y² + z²)
theta = arccos(z / r)
phi = atan2(y, x)

The reverse direction works like this: x = r * sin(theta) * cos(phi), y = r * sin(theta) * sin(phi), z = r * cos(theta). The atan2 function is critical here instead of plain atan. I spent about three weeks debugging a robotics control system in 2019 where the issue traced back to someone using atan(y/x) instead of atan2(y, x). Points in the second and third quadrants all got mapped to wrong positions, and the robot was randomly moving into obstacles it shouldn't have been able to reach. atan2 handles the quadrant ambiguity internally. Don't skip it.

Understanding Cartesian To Spherical Coordinates Conversion

One thing most tutorials gloss over is what happens at the poles. When theta equals zero or pi, the point sits directly on the z-axis and phi becomes mathematically undefined. Any value of phi would produce the same point. In practice, this isn't a problem for the forward direction (Cartesian to spherical) because atan2 will just return zero and you don't care. But when you're converting back or doing numerical differentiation near the poles, you can get singularities that break gradient-based optimization routines. I hit this in a computer graphics project where I was computing lighting gradients on a sphere. Near the poles, the numerical Jacobian became garbage because small changes in x and y produced massive swings in phi. The workaround was to detect when |z| / r was within 0.9999 of 1 and skip the phi computation entirely in those regions, falling back to a direct Cartesian gradient evaluation. It added maybe twenty lines of code and eliminated the artifact. Another counter-intuitive detail: the order of arguments to atan2 matters. In most programming languages it's atan2(y, x), not the other way around. Python, C++, JavaScript, and MATLAB all use this convention. If your codebase uses Mathematica or Wolfram Language, the function is ArcTan[x, y], which swaps the argument order. Migrating implementations between these environments silently produces incorrect results without any error message.

There's also the physics convention where the symbols are swapped - phi becomes the polar angle and theta becomes the azimuthal angle. If you're pulling formulas from different sources, always verify which convention each author is using before pasting them together. I've seen this cause entire simulation runs to produce nonsensical trajectories because one library used the math convention and another used the physics convention without anyone noticing. The main limitation of spherical coordinates is this: they aren't globally well-defined. The pole singularity, the phi ambiguity at the poles, and the fact that r is usually constrained to be non-negative means you can't represent the coordinate system smoothly over the entire sphere. For applications that involve global optimization or continuous integration over a spherical domain, people sometimes switch to quaternion representations or work directly in Cartesian space and only convert at the boundaries. It depends on what you're optimizing for. Here's a practical example. Say you have a point at x = 3, y = 4, z = 12. The radius r is sqrt(9 + 16 + 144) = sqrt(169) = 13. Theta works out to arccos(12 / 13), which is approximately 0.395 radians or about 22.6 degrees. Phi is atan2(4, 3), roughly 0.927 radians or 53.1 degrees. So the spherical representation is approximately (13, 0.395, 0.927) in (r, theta, phi) order.

If you need a reference implementation, the numpy function np.arctan2 handles the quadrant logic correctly and np.degrees or np.radians will convert between units. In production code, I'd wrap the conversion in a function that validates r is not negative and returns a consistent phi value when you're exactly at a pole rather than letting atan2 return whatever it feels like returning. For the download side of things, there isn't really a single tool people download for this. It's a basic enough transformation that you write it once in whatever language your project uses. A typical utility function is under thirty lines and takes less than a millisecond to execute for a single point. The bottleneck is never the conversion itself - it's the downstream handling of edge cases and the convention mismatches I described above.