The Math Nobody Teaches Right
I spent three years debugging a graphics engine before I realized half my bugs were just degree-radian mismatches. Not the kind of thing that makes for a dramatic story. It just happens. You write a rotation function, it looks right on paper, and then your model is spinning at exactly the wrong speed or angle and you spend two weeks chasing it. Converting degrees to radians is one of those things where the formula is trivial and the actual mistakes are invisible. The formula is multiply by /180. That's it. But here's what nobody tells you: most people don't actually convert properly because they rely on calculators set to the wrong mode, and they don't notice until the output looks wrong in a context where there's no immediate red flag.
How To Convert Deg To Rad
Take your degree value and multiply it by divided by 180. In code, that usually looks like degrees multiplied by (Math.PI / 180) in JavaScript or math.radians() in Python. In a spreadsheet, it's DEGREES * PI()/180. The result is a dimensionless number representing how many radians the angle covers. is approximately 3.14159265. So one degree is roughly 0.017453 radians. A full circle is 360 degrees or 2 radians. That's where the conversion factor comes from: 2 / 360 = /180. Here's the thing that trips people up. Trig functions in virtually every programming language expect radians. If you pass degrees directly into sin() or cos(), you get back the sine or cosine of the wrong angle. The result isn't garbage. It looks like perfectly valid numbers. They're just the values for the wrong angle. Your physics simulation doesn't crash. Your game character just moves in a slightly wrong direction and you spend hours wondering why.
I ran into this exact problem on a project where we were computing orbital trajectories. The spacecraft kept drifting off course by maybe two degrees per orbit. Two degrees sounds small. Over a thousand orbits it compounds into something catastrophic. The fix was converting the angular velocity from degrees per second to radians per second before feeding it into the integrator. After the conversion, the drift disappeared immediately. We had spent six weeks looking for bugs in the thrust model and the gravity coefficients before someone finally checked the input units.
Common Pitfalls
The biggest mistake I see is partial conversion. People convert the angle but leave the angular velocity in degrees. Or they convert the time step and not the angle. These errors are invisible because the units still "make sense" numerically. The number is reasonable. It's just wrong by a factor of /180 or 180/. Another issue is floating point precision when you're converting large angles. If you're working with something like 15,000 degrees and converting it to radians, you might expect the result to wrap cleanly around the circle. But floating point arithmetic doesn't reduce modulo 2 automatically. You end up with a large radian value that a trig function can handle but your downstream logic can't. The workaround is to normalize to [0, 2) after conversion using a proper modulo operation, not just subtraction. There's also the issue of library-specific behavior. Some libraries have a deg2rad function. Some don't. Some expect radians and some expect degrees. GLM uses radians by default. DirectX has functions that take degrees explicitly. Switching between APIs without checking the expected units is a reliable way to introduce subtle bugs.
When This Approach Fails
The /180 multiplication method works fine for most applications. But if you're doing symbolic mathematics or exact geometry, you're throwing away information by approximating as a floating point number. In those cases, keep everything in terms of . Store angles as rational multiples of instead of converting to decimal radians. A quarter turn is /2, not 1.570796327. Your calculations stay exact until the final rendering or output step. There's also a practical limitation with very small angles in certain physics simulations. When you're dealing with sub-degree precision and your time steps are already tiny, the conversion factor introduces a relative error that can accumulate. In those edge cases, it sometimes makes sense to work entirely in degrees internally and only convert at the boundaries where trig functions are called. It's less clean but it avoids compounding the conversion error across thousands of iterations. If you need a quick reference, the key values are 0°, 30°, 45°, 60°, and 90° converting to 0, /6, /4, /3, and /2 respectively. Memorizing those five helps you sanity-check your conversions without pulling out a calculator every time.
