Sin Cos And Tan

The Practical Guide to Working with Trigonometric Functions

I spent three days debugging a 2D physics simulation last year because I treated sin and cos as interchangeable. They're not. The angle convention alone killed my whole loop. Here's what I wish someone had told me before I tore my hair out. Let's just look at what these actually do instead of rehashing the unit circle definition you memorized in high school and promptly forgot. Sine takes an angle and gives you the Y component of a unit vector at that angle. Cosine gives you the X component. Tangent is the ratio of sine over cosine, and it's where most people hit their first wall because tan(/2) is undefined and your code will blow up if you're not careful about it.

Here's the thing nobody emphasizes enough: in most programming languages, these functions expect radians, not degrees. I wasted half a morning in 2019 chasing a bug where my projectile trajectory was completely wrong. The fix was multiplying every angle by /180 before passing it to the function. If your math library doesn't have a built-in degree-to-radian converter, write one and call it every time. Your future self will thank you.

When to Use Tan Instead of Sin and Cos Together

This is where it gets interesting. Tan is useful when you know an angle and need the slope of a line at that angle. But here's the trap: if you compute sin and cos separately just to divide them, you're reinventing tan and losing precision in the process. Use the dedicated tan() function when you can. It's faster and more accurate. I learned this the hard way while building a ray casting system for a retro-style renderer. I was computing direction vectors like this: angle = atan2(dy, dx)
sin_a = sin(angle)
cos_a = cos(angle)
tan_a = sin_a / cos_a

Then I realized I didn't need sin and cos at all for the ray slope calculation. I just needed tan. Dropping two trig calls per ray cut my frame rendering time by roughly 40 percent on an average machine. That's not negligible when you're pushing 60fps.

The Precision Problem Near 90 and 270 Degrees

Both sin and cos are well-behaved across their entire domain. Tan, however, approaches infinity as the angle gets close to 90° or 270°. Floating point representation means you'll never actually hit exact infinity, but you will get numbers like 1e+15 or -1e+15 that will corrupt any downstream calculation expecting reasonable magnitudes. The workaround I ended up using in my ray caster was to clamp the output of tan() to a reasonable maximum value, say 1e10, and then check whether the absolute value of the cosine component was below a threshold before dividing. When cos() drops below 0.001, I switch to using 1.0/tan() for the reciprocal calculation instead. This avoids the division-by-near-zero problem entirely without adding significant overhead.

Precomputing Values Is Usually Worth It

If you're working in a real-time system where the same angles repeat—say, a rotating turret that sweeps through a fixed arc—precompute the sin and cos tables and index into them. A lookup table of 360 entries covering 0 to 359 degrees takes negligible memory and runs significantly faster than calling the math library functions repeatedly. I built a procedural sound synthesizer once that needed to evaluate sin() at 44,100 samples per second. The CPU cost was real. A simple lookup table with linear interpolation between entries brought the processing load down to something my machine could handle comfortably. The tradeoff is that you lose sub-degree precision, but for audio synthesis at that sampling rate, you gain almost nothing from extra precision in the oscillator function itself.

Common Pitfalls I Keep Seeing

Using degrees in API calls that expect radians is still the number one mistake. Check your documentation. Always. Assuming sin(x) == sin(x + 2) in floating point. Due to rounding error, sin(2) is not exactly zero. It's approximately 2.45e-16. If you're doing accumulation over many cycles, this drift matters. Normalize your angles back into the [0, 2) range using modulo arithmetic, but be aware that negative angles behave differently depending on your language's modulo implementation. Confusing the argument order of atan2. In most languages it's atan2(y, x), not atan2(x, y). The swap is an extremely common source of bugs that manifests as objects rotating in the wrong direction or cameras pointing the wrong way.

When Trig Functions Are the Wrong Tool

If you're only ever dealing with angles that are multiples of 45° or 90°, you don't need sin or cos at all. The values are either 0, 1, -1, or ±2/2. Hardcode those. It's faster and eliminates any floating point concern entirely. For small angles—anything under about 10° or 0.17 radians—the Taylor series approximation sin(x) x is accurate enough for most applications. I used this in a particle system where most velocities were nearly horizontal. The approximation saved enough cycles per frame that I could increase the particle count by three times without any framerate drop. There's also the case where you need the angle but not the trig values themselves. If you're just comparing angles, use cross products and dot products instead of computing arcsin or arccos. Those inverse functions are expensive and lose information about which quadrant the angle is in. A single atan2() call followed by a comparison is cleaner than two separate inversions.

A Note on Libraries and Their Quirks

Not all math libraries behave the same. The C standard library, JavaScript's Math object, Python's math module, and various game engine math headers all implement these functions slightly differently, especially around edge cases and performance characteristics. If you're writing cross-platform code, test your trig calculations against known values at the boundaries—0, /2, , 3/2, and 2. A difference of even 1e-7 between platforms can cause visible desync in multiplayer environments. Most modern SIMD instruction sets include vectorized versions of sin and cos that operate on multiple data points simultaneously. If your application does batch trigonometric operations, leveraging vectorization can provide significant speedups. The AVX and SSE instruction sets both support this, and many languages have bindings that make it relatively straightforward to use.