COT

What it does

COT(number)

COT(number) returns the cotangent of an angle in radians. Microsoft's page describes it as the cotangent of an angle specified in radians.

cot x = cos x / sin x = 1 / tan x = tan(π/2 - x)

The pole structure is where the reading and the implementation part company. Mathematically there is a pole at every integer multiple of π. In binary64 only one of those poles is representable: x = 0. Every other kπ is irrational, so no double sits on it, and near those poles COT returns a large finite number rather than an error. Microsoft documents COT(0) as #DIV/0! and documents nothing about the others, which is consistent: 0 is the only argument at which the division is exactly by zero.

The consequence for a reader is worth stating plainly. COT(PI()) is not an error and is not infinite; it is roughly the reciprocal of the distance between the double PI() and the true π, which is a large number whose value says more about the rounding of PI() than about the cotangent.

Arguments

Microsoft states the magnitude constraint on this page and states #NUM! when it is exceeded. The bound is 2^27 ≈ 1.342 × 10^8, and it is not arbitrary: it is approximately where a reduction against a limited-precision π stops producing a reduced argument with any correct bits. Documenting the bound rather than returning noise is, from a numerical-analysis point of view, the right call, and it is a choice the older surfaces (COS, SIN, TAN) do not make on their own documentation pages.

Try it

Quirks

Result and edge cases

Returns Number.

• COT(0) — #DIV/0!, documented explicitly.
• Near other poles — a large finite value, not an error. The magnitude is bounded by roughly 1/ulp(kπ), so it grows with k.
• Sign near a pole — cot changes sign across every pole, so two adjacent doubles either side of kπ give large values of opposite sign. Any formula that uses COT near a multiple of π is sitting on a discontinuity of magnitude ~2/ulp.
• Zeros — at π/2 + kπ, again not representable, so COT of a double is essentially never exactly zero.
• Beyond 2^27 — documented #NUM!.
• Small arguments — cot x → 1/x, so COT of a tiny argument is a huge finite number and overflows only for |x| below about 5.6 × 10^-309, i.e. in the subnormal range.

Errors

As documented on Microsoft's COT page:

COT is the only member of its trio whose page states the zero case. CSC's page defines CSC(n) as 1/SIN(n) — which makes CSC(0) a division by zero — but does not state the resulting error; SEC has no zero-pole at all. That asymmetry is in Microsoft's documentation, not in the mathematics.

How to implement

Numerical notes

Cotangent inherits every difficulty of the tangent and adds one of its own.

The reduction problem, inherited. As on COS, evaluating a circular function at a large argument requires reducing modulo π/2 against a sufficiently precise π. COT's documented 2^27 bound is a declaration of exactly where the implementation's reduction gives up. EV-MATH-0004 identifies the substrate as the x87 FSIN/FPTAN chain with FPREM1 reduction against the 64-bit ROM π, with the reciprocal surfaces formed from the published primaries, and it rules out Cody–Waite reduction against extended π. All six circular surfaces in that record inherit a host-CPU microcode caveat, so the last bits here are platform-scoped by construction. The record's figures render in the evidence layer beside this page.

The conditioning problem, its own. The relative condition number of cot is |x / (sin x cos x)| · |cos x / sin x|^{-1}… stated more usefully: near a pole kπ, cot x ≈ 1/(x - kπ), so a relative error ε in the reduced argument becomes a relative error of about ε · |x| / |x - kπ| in the result. Close to a pole this amplification is unbounded. This is not a fixable defect; it is the function. It does mean that "how accurate is COT?" has no single answer — accuracy has to be quoted as a function of distance to the nearest pole.

The double-rounding problem, structural. Building COT as 1/TAN(x) where TAN(x) is the published binary64 tangent means the tangent's own rounding error is inverted along with the value. The result is a correctly-rounded reciprocal of an incorrectly-rounded tangent — which is a different function from a correctly-rounded cotangent, and differs from it by up to about one ulp more than the tangent already did. A natural-best implementation would instead evaluate cos r / sin r from a single reduction, sharing the reduced argument between numerator and denominator so the pole locations agree exactly.

Near zero. For small |x|, 1/TAN(x) is fine — tan x → x with no cancellation — but the Laurent form 1/x - x/3 - x³/45 (A&S 4.3.70) is cheaper and more accurate, and it is the standard choice below about 2^-13.

Muller's treatment is the reference for why the tangent family is the hardest of the circular set to round correctly: the worst cases require more extra precision than sine or cosine do, because the function is unbounded and its hardest-to-round arguments cluster near the poles.

Rust code

12 cot "COT" (1, 1) [V "number"] |s, a, sv| { unary(s, a, k::cot::cot_kernel) }

pub fn cot_kernel(n: f64) -> Result<f64, WorksheetErrorCode> {
    ExcelRealPolicy::CIRCULAR_TRIG.check_arg(n)?;
    // W109 G4-01: COT = RN53(RN64(1/TAN)) over the published TAN chain
    // (the double-rounded x87 reciprocal, unique surviving staging).
    let tan = crate::ported::excel_numeric::excel_tan(n);
    if tan == 0.0 {
        return Err(WorksheetErrorCode::Div0);
    }
    Ok(crate::ported::excel_numeric::excel_x87_recip(tan))
}

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-COT-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-COT-002: 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

• TAN — the reciprocal, and the surface COT is built from. EV-MATH-0004 records that the three reciprocal surfaces are formed as excel_x87_recip of the published primaries; for COT the primary is the tangent chain (FPTAN). That construction is the single most useful implementation fact on this page.
• COS, SIN — the ratio definition. Note that COS(x)/SIN(x) and 1/TAN(x) are different computations with different error, even though they are the same function: the first divides two rounded values, the second inverts one.
• ACOT — the inverse, principal range (0, π). Note that ACOT in Excel returns a value in (0, π) rather than (-π/2, π/2), so ACOT(COT(x)) folds into (0, π).
• CSC, SEC — the other two reciprocals introduced alongside COT, sharing its documentation template and its constraint.
• IMCOT — the complex-argument version.

Named variants

No named variants are recorded yet.