COS

What it does

COS(number)

COS(number) returns the cosine of an angle in radians. Microsoft's page says exactly that, and adds the conversion note: use RADIANS(x) or multiply degrees by PI()/180.

The mathematics, as A&S chapter 4.3 states it:

cos z = (e^{iz} + e^{-iz}) / 2
cos x = 1 - x²/2! + x⁴/4! - x⁶/6! + …          (convergent for all x)

The row that carries the most practical weight is the one about zeros. π/2 is irrational, so no double is exactly a zero of the cosine; COS(PI()/2) is not zero and cannot honestly be expected to be. What it is equals, to first order, the distance from the double PI()/2 to the true π/2 — which makes it a direct readout of how well the constant is rounded, not a defect in the cosine.

There is no analytic difficulty in cosine anywhere. It is entire, it is bounded, and its Taylor series converges everywhere. The entire numerical problem is argument reduction, and that is the subject of the numerical notes.

Arguments

Try it

Quirks

Result and edge cases

Returns Number in [-1, 1].

• Zero — COS(0) = 1 exactly, and that is the one value the function returns exactly for a reason rather than by luck.
• Large arguments — mathematically well defined and, for a double argument, a perfectly determinate real number: a double is an exact rational, so cos of it has one true value. The question is only whether an implementation computes it. See below.
• COS(PI()) — not exactly -1, for the same reason COS(PI()/2) is not exactly 0.
• Overflow is impossible. The output is bounded, so the non_finite=num half of the real-result policy can only fire because of the argument guard, never because of the value.
• Degrees. The single most common wrong answer from this function is a correct cosine of the wrong angle. Microsoft's page pre-empts it; the Handbook repeats it.

Errors

Microsoft's COS page documents no error conditions. The shared call model supplies the rest: non-numeric text in the numeric slot surfaces #VALUE!, and an error value in the argument propagates. The mechanically rendered battery beside this page shows the boundary probes.

If the circular_trig_overflow guard noted above corresponds to Excel behaviour, a large enough argument would produce #NUM! — an outcome Microsoft's page does not document for COS. That is stated here as an open question, not as behaviour.

How to implement

Numerical notes

Cosine is the textbook case where the interesting error is committed before the approximation starts.

The reduction problem. To evaluate cos x you write x = k·(π/2) + r with |r| ≤ π/4, then use a polynomial in r and a quadrant rule. Since π/2 is irrational, computing r requires the true π/2 to enough bits. If the reduction uses a π/2 stored to p bits, the computed r carries an absolute error of roughly |x| · 2^-p, and because cos has unit derivative near its zeros, that absolute error passes straight into the result. For |x| near 2^30 and a 64-bit stored constant the reduced argument can be wrong in its leading bits; by |x| near 2^60 it can be entirely noise.

The three standard answers:

1. Cody & Waite two- or three-part reduction: split the constant into exactly representable pieces and accumulate x - k·π/2 in stages. Cheap, and correct only up to a stated argument magnitude, which the authors state.
2. Payne–Hanek infinite-precision reduction: multiply by a long stored expansion of 2/π and keep only the fractional part. Correct for every finite double, at real cost. This is what a math-correct flavour must do.
3. Hardware reduction — the x87 FPREM1 instruction reduces against a π stored in ROM to 66 bits. Fast, and its accuracy ceiling is that constant.

What the evidence says. EV-MATH-0004 is a substrate identification covering all six circular surfaces, each scored individually. It names the substrate as the x87 FSIN/FPTAN chain with FPREM1 argument reduction against the 64-bit ROM π, and it records that Cody–Waite reduction against extended π is ruled out — the pre-sign-off catalogue row recorded large argument-reduction drift in the moderate-to-large range, which is the fingerprint of a limited-precision reduction constant rather than a bad polynomial. The figures live in the evidence layer and render beside this page. The record also carries a host-CPU microcode caveat on FPREM1/FSIN/FPTAN: an answer produced through those instructions is a property of the CPU as much as of the software, so this surface's last bits are platform-scoped by construction.

The polynomial half is the easy half. Once |r| ≤ π/4, a minimax polynomial in r² of modest degree delivers well under an ulp; A&S 4.3.98–4.3.99 gives the classical coefficient sets, fdlibm's __kernel_cos is the standard modern reference, and correctly-rounded implementations (CRlibm, and the CORE-MATH successors) show the achievable target.

A note for anyone building SEC or comparing against it: computing 1/COS(x) from the published (already rounded to binary64) cosine double-rounds — the cosine's own error is inverted along with the value. That is a different function from a directly-evaluated secant, and EV-MATH-0004 records the reciprocal construction explicitly.

Rust code

10 cos "COS" (1, 1) [V "number"] |s, a, sv| {
    raw(s, a, ExcelRealPolicy::CIRCULAR_TRIG, k::cos::cos_kernel)
}

/// W109 G4-01: the COS π/2-quadrant chain with the |x| < 2^-26 -> 1.0
/// shortcut (see `excel_numeric::excel_cos`).
pub fn cos_kernel(n: f64) -> f64 {
    crate::ported::excel_numeric::excel_cos(n)
}

No implementation has been published with a Handbook test suite for this function.

Version differences

The recorded environments below distinguish a reading from a same-input comparison. Counts describe captured inputs in each environment; overlapping captures and comparisons are not totals of unique worksheet calls.

• XC-COS-001: build 19929 versus build 20430; 1 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.
• XC-COS-002: build 20131 versus build 20228; 1 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.
• XC-COS-003: build 20131 versus build 20430; 1 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.

Agreement on these compared inputs does not establish agreement on unmeasured inputs.

Recorded environments and comparison details.

Alternatives

Relationships

• SIN, TAN — the other two published primaries. EV-MATH-0004 treats all six circular functions as one identification problem, and it is the right way to read them.
• SEC — the reciprocal, 1/COS. EV-MATH-0004 records that the reciprocal surfaces are built from the published primaries, which matters: see the numerical notes.
• ACOS — the inverse, principal branch [0, π]. ACOS(COS(x)) recovers x only on [0, π]; elsewhere it returns the folded representative.
• COSH — the hyperbolic partner, cosh x = cos(ix). The name is the only thing they share computationally: COSH overflows and has no reduction problem, COS cannot overflow and has nothing but a reduction problem.
• RADIANS, DEGREES — the unit converters that stand between this function and most spreadsheet users.
• IMCOS — the complex-argument version, which needs COS, SIN, COSH and SINH together.
• PI() — the constant whose rounding sets the error at every "should be zero" point.

Named variants

No named variants are recorded yet.