C cos() Function: Correctness, Portability, and Practical Patterns

You don’t notice cosine until you ship something that moves, oscillates, or points in the wrong direction.\n\nThe first time I saw cos() “misbehave” in production, the code wasn’t wrong in the obvious way—no missing header, no typo—yet the output jittered and drifted over time. The real issue was unit discipline (degrees sneaking into a radians API), plus a few quiet portability assumptions about constants and linking. If you write C in 2026—whether it’s embedded firmware, simulation code, a game loop, or a signal-processing pipeline—cos() is one of those functions you’ll keep touching, and small mistakes compound fast.\n\nI’ll walk you through how cos() is defined, how to call it correctly, how to compile and link it reliably across toolchains, and what to watch for with accuracy, edge cases, and performance. I’ll also show a few complete examples I’ve used in real codebases: angle conversion that doesn’t surprise you later, point rotation, and generating a cosine wave buffer you can feed into audio or DSP.\n\n## What cos() actually computes (and why radians matter)\nAt a high level, cos(x) returns the cosine of an angle x measured in radians.\n\nIn a right triangle, cosine is “adjacent over hypotenuse,” but in code you should think in terms of the unit circle: for an angle x, cos(x) gives the x-coordinate of the point on the unit circle at that angle. That mental model scales better when you move beyond triangles into rotations, matrices, and periodic signals.\n\nThe C signature is:\n\n #include \n\n double cos(double x);\n\nKey details I keep in mind:\n\n- Input is radians. If your code thinks in degrees, you must convert.\n- Domain is all real numbers. Any finite double is accepted (plus NaN and infinities, which have special behavior).\n- Return is double. If you’re working in float, call cosf. If you’re working in extended precision, call cosl.\n\nA quick reality check with a familiar angle:\n\n- 45 degrees is \(\pi/4\) radians.\n- cos(pi/4) is approximately 0.70710678…\n\nIf you accidentally pass 45 directly to cos(45), you’re asking for the cosine of 45 radians, which is a totally different angle (about 2578 degrees). The result isn’t “slightly off”—it’s unrelated to what you intended.\n\nWhen I review numeric code, unit mistakes around trig calls are one of the most common bugs, and they often survive testing because the program still “looks like it runs.”\n\n## Headers, linking, and the parts that break across platforms\nThe header story is simple: include . The build story is where people get burned.\n\n### Include the right header\nYou want:\n\n #include \n\nWithout it, older C compilers may assume an implicit declaration (or warn/error under modern settings). Under strict flags, you’ll get diagnostics like “implicit declaration of function ‘cos’” or mismatched prototypes.\n\nIn practice, I compile numeric C with warnings high enough that missing headers don’t slip by: -Wall -Wextra -Wpedantic (and often -Werror in CI).\n\n### Link the math library (common on Unix-like systems)\nOn many Linux toolchains, math functions live in libm, so you need -lm:\n\n gcc -std=c17 -O2 -Wall -Wextra -pedantic cosdemo.c -lm\n\nI recommend putting -lm at the end of the link line, because traditional linkers resolve libraries left-to-right.\n\nOn macOS, -lm is typically not required, but it doesn’t hurt. On Windows/MSVC, the CRT provides math functions without a separate -lm flag.\n\n### Don’t assume MPI exists everywhere\nA lot of samples use MPI from . In practice:\n\n- Some environments define it by default.\n- Others hide it behind feature macros.\n- Some standard modes won’t expose it at all.\n\nIf you want something that behaves consistently, I usually compute π as acos(-1.0) once:\n\n static double pi(void) {\n return acos(-1.0);\n }\n\nThat’s readable, portable, and avoids build-system arguments about feature macros.\n\n### Prefer cosf/cosl when the type should match\nA subtle performance and correctness habit:\n\n- If you store angles in float, call cosf(anglef).\n- If you store angles in long double, call cosl(angleld).\n\nCalling cos() with a float promotes the value to double anyway, which may be fine, but it can create conversions in tight loops you didn’t plan for.\n\n### A quick portability checklist I use\nWhen I’m trying to make trig-heavy code build across Linux, macOS, Windows, and at least one embedded toolchain, I check these items early:\n\n- #include present at every trig call site (or via a shared header).\n- -lm used where required (especially GCC/Clang on Linux).\n- No reliance on non-standard macros/constants unless guarded (MPI, MPIf, etc.).\n- Correct function variant (cosf, cos, cosl) to match the data path.\n- -fno-builtin only if I truly need it (rare); otherwise let the compiler do its job.\n\n## Degrees-to-radians conversion you won’t regret later\nMost real systems (CAD, UI sliders, sensor readouts) speak degrees, but cos() speaks radians. I treat conversion as an API boundary issue: convert once at the boundary, then keep radians internally.\n\nHere’s a small, reusable conversion layer that also avoids depending on MPI.\n\n // degradcos.c\n #include \n #include \n\n static double pi(void) {\n // Portable way to get pi without relying on MPI.\n return acos(-1.0);\n }\n\n static double degtorad(double degrees) {\n return degrees (pi() / 180.0);\n }\n\n int main(void) {\n double degreeslist[] = { 30.0, 45.0, 60.0, 90.0 };\n sizet n = sizeof(degreeslist) / sizeof(degreeslist[0]);\n\n for (sizet i = 0; i < n; i++) {\n double deg = degreeslist[i];\n double rad = degtorad(deg);\n double c = cos(rad);\n\n printf("cos(%.1f deg) = cos(%.6f rad) = %.6f\n", deg, rad, c);\n }\n\n return 0;\n }\n\nWhat I like about this pattern:\n\n- The conversion is obvious and centralized.\n- The call site stays honest: cos(rad) reads correctly.\n- Your logs can print both degrees and radians when debugging.\n\nIf you want to be stricter, you can encode units in types (common in C++), but in C I usually rely on naming conventions: anglerad, angledeg. In practice, that naming discipline prevents more bugs than any amount of commenting.\n\n### An even stricter boundary pattern (I actually use this)\nIf a module receives degrees from the outside world but stores radians internally, I’ll sometimes forbid radians from being passed in accidentally by making the conversion the only public entry point. In plain C, that usually means the header exports something like setheadingdegrees(...) and the .c file owns the internal radian value. It’s not fancy, but it stops “just pass the number in” mistakes.\n\n## cos(), cosf(), cosl(): picking the right one\nC gives you a family of cosine functions so you can match the precision (and sometimes performance) to your data.\n\n- double cos(double x)\n- float cosf(float x)\n- long double cosl(long double x)\n\nWhen does it matter?\n\n- In graphics/audio, float pipelines are common. Using cosf avoids widening and can help vectorization or reduce register pressure.\n- In simulation/robotics, double is common because errors accumulate over time or across transforms.\n- In a few niches (some scientific computing, or platforms where long double is meaningfully wider than double), cosl can be useful—but don’t assume long double is wider on every platform.\n\nIf you want to write generic-looking code without macros, a practical compromise is to choose a project-wide scalar type and stick with the matching trig functions. I’ve shipped codebases where typedef float realt; is paired with #define REALCOS cosf and so on. It’s blunt, but it works.\n\n## Precision, rounding, and what happens for huge angles\nIn day-to-day code, cos() feels like magic: pass a number, get a number. Under the hood, the math library does range reduction (bringing large angles back into a neighborhood where polynomial approximations behave well), then computes the value with a target error bound.\n\n### Finite precision means “close,” not “exact”\nEven for “simple” angles, you should expect slight rounding:\n\n- cos(pi()/2) might print as 6.123233995736766e-17 instead of 0.0.\n\nThat’s not a bug; it’s floating-point arithmetic. If you compare the result to 0.0 exactly, you’ll eventually get bitten.\n\nI recommend a tolerance check:\n\n #include \n\n static int nearlyequal(double a, double b, double releps, double abseps) {\n double diff = fabs(a – b);\n if (diff <= abseps) return 1;\n double maxab = fmax(fabs(a), fabs(b));\n return diff <= maxab releps;\n }\n\nThen:\n\n- Use abseps for values near zero.\n- Use releps for values with meaningful magnitude.\n\nA rule of thumb that holds up well in practice: start with releps = 1e-12 and abseps = 1e-15 for double (looser for float), then tighten or loosen based on your domain and test results.\n\n### Very large x loses phase detail\nThe x parameter can be from negative to positive infinity in the type system, but for extremely large magnitudes the function may not preserve fine-grained changes in angle.\n\nReason: when

is huge, the spacing between representable double values becomes large too, and x + tinydelta may round back to x. So even if your algorithm thinks it’s advancing phase smoothly, the numeric representation can’t carry that information.\n\nPractical guidance I follow:\n\n- If you’re integrating angle over time, wrap it periodically into a small range, like [-pi, pi] or [0, 2pi).\n- If you’re generating periodic signals, keep a phase accumulator in a bounded interval.\n\nHere’s a safe wrapping helper:\n\n #include \n\n static double wrap0to2pi(double x) {\n double twopi = 2.0 acos(-1.0);\n double y = fmod(x, twopi);\n if (y < 0.0) y += twopi;\n return y;\n }\n\nThis doesn’t make the function “more correct” so much as it keeps your data in a numeric range where double has plenty of resolution.\n\n### Special values: NaN and infinities\nMost standard libraries follow IEEE-754 conventions:\n\n- cos(NAN) returns NAN.\n- cos(+INF) and cos(-INF) typically return NAN and may raise a floating-point exception.\n\nFor robust systems, I like to validate inputs at subsystem boundaries:\n\n #include \n\n if (!isfinite(anglerad)) {\n // Decide policy: clamp, return error, or propagate NaN.\n }\n\nIf you’re writing safety-related firmware, you probably don’t want NaNs silently creeping into control outputs.\n\n### What the standard does (and doesn’t) promise\nThis is the part I keep mentally separate: C specifies the function interface and broad behavior, but not a single universal implementation. Two different libm implementations can return slightly different last-bit results for the same input, and both can be correct.\n\nSo when I write tests, I avoid “must equal this exact floating literal” unless the input is something extremely stable (and even then I prefer tolerance tests).\n\n## Error handling: errno, floating exceptions, and input validation\nIn most production code, I don’t handle trig errors the way people handle file I/O errors—because trig isn’t “supposed” to fail for finite inputs. But it can still matter if your system is sensitive to NaNs/Infs or if you intentionally trap invalid floating operations.\n\n### matherrhandling and errno\nC has a macro matherrhandling that tells you whether the math library reports errors via errno, floating-point exceptions, or both. In practice:\n\n- Many systems use floating-point exceptions for things like invalid operations.\n- errno is less commonly relied upon for trig.\n\nIf you’re in a strict environment where errno must remain untouched (performance-sensitive logging, certain real-time code), avoid writing code that assumes errno is meaningful after cos().\n\n### A pragmatic “safe cosine” wrapper\nWhen I’m wiring together components that can produce garbage values (sensor spikes, uninitialized memory, corrupted packets), I sometimes wrap trig with an explicit policy. Example: return 1.0 for non-finite angles (or return an error code—pick what fits your system).\n\n #include \n\n static int safecos(double anglerad, double out) {\n if (!out) return 0;\n if (!isfinite(anglerad)) {\n out = 1.0;\n return 0;\n }\n out = cos(anglerad);\n return 1;\n }\n\nI’m not claiming this is mathematically pure. It’s operational: it prevents a single NaN from contaminating an entire control loop or rendering pipeline.\n\n## Performance: what matters in 2026 builds (and what usually doesn’t)\nMost of the time, cos() is not the hottest part of your program. When it is, you’ll feel it: trig calls tend to be expensive compared to basic arithmetic, and they can limit throughput in inner loops.\n\nHere’s how I approach performance without turning the code into a science project.\n\n### Prefer the right function and type\n- Use cosf in float pipelines (common in audio, graphics, ML preprocessing).\n- Use cos in double pipelines (common in simulation, robotics).\n\nThis avoids unnecessary conversions.\n\n### Compute both sine and cosine together when needed\nA common pattern is computing sin(x) and cos(x) for the same x (rotation matrices, complex numbers). Many platforms provide sincos() as an extension that computes both with shared range reduction.\n\nBecause it’s not standard C, I treat it as an optional fast path:\n\n- If you control the platform (Linux/embedded with common libm variants), it can be a win.\n- If you need portability (Windows/MSVC, strict standard libs), stick to separate calls.\n\nIf you keep separate calls, a decent compiler may still combine work depending on flags and the math library, but you shouldn’t count on it.\n\n### Be careful with “fast math” flags\nCompilers can change floating-point semantics under flags like -ffast-math. You might get faster trig, but you can also lose properties you assumed:\n\n- NaN/Inf handling can change.\n- Signed zero behavior can change.\n- Reassociation can alter results.\n\nIn my experience, it’s worth enabling fast-math only when you:\n\n- Have tests that tolerate small numeric differences.\n- Know the input domain (no NaNs/Infs).\n- Benchmark on the actual target CPU.\n\n### Denormals and “mysterious” slowdowns\nIf you’re doing DSP-like work (filters, oscillators, window functions), extremely small floating values can become subnormal (denormal) numbers on some CPUs, which can be much slower to process depending on the hardware and mode.\n\ncos() itself usually won’t emit subnormals for typical phase values, but downstream math might (especially if you multiply by tiny amplitudes or differences). If performance suddenly tanks after a fade-out, subnormals are one of the first things I check.\n\n### Table: Traditional vs modern loop practices\nWhen I’m modernizing C numeric code in 2026, I usually see the same handful of improvements.\n\n

\n\nIf you’re using AI-assisted coding tools, they’re great at producing trig-heavy code quickly, but they’re also great at sneaking in degrees/radians mistakes and silent integer division. I still review those call sites manually.\n\n## Real-world patterns: rotations, wave generation, and sensor math\nThis is where cos() stops being a textbook function and becomes a building block.\n\n### 1) Rotate a 2D point around the origin\nA classic: given point (x, y) and angle θ, rotate by:\n\n- x‘ = xcos(θ) - ysin(θ)\n- y‘ = xsin(θ) + ycos(θ)\n\nRunnable example:\n\n // rotatepoint.c\n #include \n #include \n\n typedef struct {\n double x;\n double y;\n } Vec2;\n\n static double pi(void) {\n return acos(-1.0);\n }\n\n static double degtorad(double degrees) {\n return degrees (pi() / 180.0);\n }\n\n static Vec2 rotate(Vec2 v, double thetarad) {\n double c = cos(thetarad);\n double s = sin(thetarad);\n\n Vec2 out;\n out.x = v.x c – v.y s;\n out.y = v.x s + v.y c;\n return out;\n }\n\n int main(void) {\n Vec2 p = { .x = 10.0, .y = 0.0 };\n double theta = degtorad(30.0);\n\n Vec2 q = rotate(p, theta);\n printf("(%.3f, %.3f) rotated by 30 deg -> (%.3f, %.3f)\n", p.x, p.y, q.x, q.y);\n\n return 0;\n }\n\nThis pattern shows a nice property: cos() and sin() appear together. If your system needs thousands of rotations per frame (games, robotics), that’s where you start caring about batching, float vs double, and possibly a combined sine/cosine call if your platform offers it.\n\n### 2) Generate a cosine wave buffer (audio/DSP)\nIf you generate samples for a tone or a test signal, you’ll often compute:\n\n- sample[n] = amplitude cos(phase)\n- phase += 2pifreq/samplerate\n- wrap phase back into [0, 2pi)\n\nRunnable example:\n\n // cosinewave.c\n #include \n #include \n\n static double pi(void) {\n return acos(-1.0);\n }\n\n static double wrap0to2pi(double x) {\n double twopi = 2.0 pi();\n double y = fmod(x, twopi);\n if (y < 0.0) y += twopi;\n return y;\n }\n\n int main(void) {\n const double samplerate = 48000.0;\n const double freq = 440.0; // A4\n const double amplitude = 0.8;\n const int frames = 16; // small demo buffer\n\n double phase = 0.0;\n double phasestep = 2.0 pi() freq / samplerate;\n\n for (int n = 0; n < frames; n++) {\n double value = amplitude cos(phase);\n printf("%2d: %.8f\n", n, value);\n\n phase = wrap0to2pi(phase + phasestep);\n }\n\n return 0;\n }\n\nIf you skip the wrapping and let phase grow for hours, you’ll eventually lose resolution and the waveform can drift or pick up noise. Wrapping keeps the numeric representation stable.\n\n### 3) Sensor and control math (small-angle behavior)\nIn robotics and control, cosine shows up in:\n\n- projecting a vector onto an axis\n- converting between frames\n- energy calculations\n\nA practical note: for very small angles, cos(θ) is close to 1.0. If you subtract it from 1.0, you can lose precision due to catastrophic cancellation.\n\nIf you need 1 - cos(θ) for tiny θ, consider rewriting your math (for example, using 2sin^2(θ/2)), which can behave better numerically. This is the kind of tweak that matters in filters and estimators where tiny deltas accumulate.\n\n## More practical patterns I keep reaching for\nThese are the “not in the textbook, but constantly in code” uses of cosine that add real value once you’ve moved past cos(pi/3).\n\n### 4) Rotate around an arbitrary center (UI, CAD, games)\nMost real rotations aren’t around the origin—they’re around a pivot. The pattern is always: translate to pivot, rotate, translate back.\n\n // rotateabout.c\n #include \n\n typedef struct { double x, y; } Vec2;\n\n static Vec2 rotateabout(Vec2 p, Vec2 center, double thetarad) {\n double c = cos(thetarad);\n double s = sin(thetarad);\n\n double dx = p.x – center.x;\n double dy = p.y – center.y;\n\n Vec2 out;\n out.x = center.x + (dx c – dy s);\n out.y = center.y + (dx s + dy c);\n return out;\n }\n\nWhat I like: it makes unit errors obvious. If your UI slider is “degrees,” you’ll see immediately where the conversion belongs.\n\n### 5) Dot product and the “cosine of the angle” (geometry, ML, ranking)\nCosine also shows up indirectly: the dot product identity\n\n- a · b =

)\n- then θ = acos(cos(θ))\n\nTwo practical notes from real code reviews:\n\n1) The value you feed into acos should be clamped to [-1, 1] because rounding can push it slightly outside.\n2) If you only need a similarity score, don’t compute acos at all—use the cosine similarity directly.\n\n### 6) Window functions: Hann window (DSP)\nIf you’ve ever smoothed a signal, reduced spectral leakage, or shaped an audio buffer, you’ve probably used a cosine window. A common one is the Hann window:\n\n- w[n] = 0.5 (1 - cos(2pin/(N-1)))\n\nThis is a perfect example of where 1 - cos(...) appears, and where rewriting might matter if you’re extremely sensitive near endpoints. In most audio uses it’s fine as written, but it’s worth knowing why the endpoints don’t always print as exactly zero—floating-point and pi approximations again.\n\n### 7) Cosine interpolation (animation and “nice feeling” easing)\nCosine can be used to ease between values smoothly. A classic cosine ease-in-out from a to b over t in [0, 1] is:\n\n- mu = (1 - cos(pit)) / 2\n- value = a(1-mu) + bmu\n\nI’ve used this in camera smoothing, UI transitions, and even simple motion planning where I wanted something smoother than linear interpolation but didn’t want to pull in a full easing library.\n\n## Edge cases and numerical “gotchas” that show up in production\nThis section is basically a collection of scars. The math is fine; the engineering details are where things go sideways.\n\n### Cosine is even, periodic, and bounded—use those facts to sanity-check\nThere are a few properties that are always true (for real inputs) and make great debug checks:\n\n- Even function: cos(-x) == cos(x) (within rounding).\n- Periodicity: cos(x + 2pik) == cos(x) for integer k.\n- Bounded: result is in [-1, 1] for finite real x (again, within tiny rounding).\n\nIf my output is 1.0000002, something upstream is wrong (or I’m printing with insufficient precision and misreading it). If cos(-x) differs wildly from cos(x), I suspect NaN propagation or an uninitialized variable.\n\n### If you store angles in integers, you will eventually regret it\nI’ve seen people store degrees in int because “we only need whole degrees.” Then six months later someone adds smoothing, or a sensor arrives with fractional degrees, or a control system needs sub-degree resolution. The first fix is usually “convert to double at the call site,” and now half the code is in degrees, half is in radians, and nothing is consistent.\n\nIf you must store an angle compactly (embedded constraints), I prefer either:\n\n- fixed-point radians with a clearly documented scale factor, or\n- store phase as a normalized [0, 1) fraction of a full turn (and convert once).\n\n### Modulo and wrapping: choose the interval that matches your algorithm\nWrapping to [0, 2pi) is common for oscillators. Wrapping to [-pi, pi] can be better for control error angles because it makes “smallest difference” logic natural.\n\nIf you’re computing an error like target - current, wrap the difference, not the absolute angles, unless you’re certain the subtraction won’t cross boundaries in a surprising way.\n\n## Common mistakes I see (and the checklist I use to fix them)\nWhen cos() outputs a number you didn’t expect, the bug is usually not inside cos(). It’s in your assumptions.\n\n### Mistake 1: Passing degrees\nSymptom: cos(90) not close to zero.\n\nFix: convert degrees to radians at the boundary, store radians internally.\n\n### Mistake 2: Integer division sneaking into conversions\nThis one is painful because it looks correct at a glance:\n\n // Wrong: 3/180 is integer division => 0\n anglerad = angledeg (3 / 180);\n\nFix: ensure floating literals (and don’t hardcode 3 for pi):\n\n anglerad = angledeg (pi() / 180.0);\n\n### Mistake 3: Assuming MPI exists\nSymptom: build fails on one platform or under strict standard flags.\n\nFix: compute π via acos(-1.0) or define your own constant in a project header.\n\n### Mistake 4: Forgetting -lm on Linux\nSymptom: link errors like “undefined reference to cos”.\n\nFix: add -lm at link time (and keep it after object files).\n\n### Mistake 5: Comparing floating results for exact equality\nSymptom: tests fail intermittently or only on some CPUs.\n\nFix: compare within tolerances (nearlyequal), and test properties rather than single exact constants when possible.\n\n### Mistake 6: Letting angles grow without bounds\nSymptom: long-running systems slowly drift, jitter, or stop responding to tiny phase changes.\n\nFix: wrap phase into a bounded interval periodically (use fmod, or maintain a normalized phase in [0, 1)).\n\n### Mistake 7: Mixing float storage with double trig (or vice versa)\nSymptom: performance regressions in hot loops, or subtle differences across platforms because conversions happen in different places.\n\nFix: decide your numeric type per subsystem and use cosf/cos consistently.\n\n### Mistake 8: Feeding acos values slightly outside [-1, 1]\nSymptom: NaNs appear when computing angles from dot products.\n\nFix: clamp before acos (this is a rounding issue, not “bad math”).\n\n### Mistake 9: Recomputing π and constants in tight loops\nSymptom: wasted cycles, noisy profiles, and sometimes inconsistent constants if implemented differently in multiple files.\n\nFix: compute constants once per module (or store them in a shared header as static const double).\n\n## Alternative approaches (when cos() isn’t the right tool)\nI like standard library math, but there are real cases where I don’t call cos() directly.\n\n### 1) Small-angle approximations\nIf θ is guaranteed tiny, you can approximate:\n\n- cos(θ) ≈ 1 - θ²/2\n\nThis can be faster and “good enough” in certain embedded contexts, but it’s dangerous if the input escapes your intended range. If I do this, I enforce the range with asserts in debug builds (and often runtime clamps in production builds for safety).\n\n### 2) Lookup tables\nIn microcontrollers without a fast FPU, a lookup table can be a win. But tables have their own engineering costs:\n\n- memory footprint\n- interpolation errors\n- periodicity/wrapping correctness\n- unit and scaling correctness\n\nIf you go this route, I strongly recommend basing the table on a normalized phase [0, 1) (or [0, 2pi)) and writing exhaustive tests for boundary cases (index 0, index N-1, wrap-around).\n\n### 3) CORDIC and fixed-point trig\nFor some embedded targets, CORDIC is a reasonable approach. It’s beyond the scope of this article to implement fully, but my practical rule is: only do it if you’re forced by hardware constraints, and treat it like a mini math library with its own verification suite.\n\n## Testing and debugging cosine-heavy code (what I actually do)\nThis is the difference between “it works on my machine” and “it works for months in production.”\n\n### Unit tests that pay off quickly\nIf I’m writing tests around cosine, I test properties and known reference points with tolerances:\n\n- cos(0) ≈ 1\n- cos(pi) ≈ -1\n- cos(pi/2) ≈ 0\n- evenness: cos(x) ≈ cos(-x)\n- periodicity: cos(x) ≈ cos(x + 2pi)\n\nI also add a couple of random tests for sanity: generate random x values within a reasonable range (say [-1000, 1000]) and check invariants like cos(x) in [-1, 1] and the identity cos²(x) + sin²(x) ≈ 1 (within tolerance).\n\n### Logging that makes unit errors obvious\nWhen I suspect degrees/radians mistakes, I log both forms for a short time window:\n\n- angledeg\n- anglerad\n- cos(anglerad)\n\nIf anglerad is around 90.0 when I expected ~1.57, the bug is already found.\n\n### One habit that prevents half my trig bugs\nI name variables with units: thetarad, headingdeg, phaserad, omegarad_s. It’s not glamorous, but it saves real time.\n\n## Expansion Strategy\nAdd new sections or deepen existing ones with:\n\n- Deeper code examples: More complete, real-world implementations\n- Edge cases: What breaks and how to handle it\n- Practical scenarios: When to use vs when NOT to use\n- Performance considerations: Before/after comparisons (use ranges, not exact numbers)\n- Common pitfalls: Mistakes developers make and how to avoid them\n- Alternative approaches: Different ways to solve the same problem\n\n## If Relevant to Topic\n- Modern tooling and AI-assisted workflows (for infrastructure/framework topics)\n- Comparison tables for Traditional vs Modern approaches\n- Production considerations: deployment, monitoring, scaling\n\n—\n\nIf you take nothing else from this: cos() is reliable, but your usage has to be disciplined. Convert units at the boundary, keep phase bounded, compare floats with tolerances, and make portability decisions explicit (headers, linking, constants). That’s how cosine stays boring—in the best way—when your system is running at 60 FPS, 48 kHz, or 24/7 for months.