COT
Quirk foundCategory: Math and trigonometry · Last tested 2026-09-01
Real compatibility results for the COT function: executed in Excel for the web, Google Sheets and LibreOffice Calc, with desktop Excel behavior from Microsoft’s official documentation (we do not run desktop Excel — Excel for the web is a different application and is executed separately). Syntax and links to that documentation are below.
Support matrix
| Engine | Documented | Live-tested | Verdict |
|---|---|---|---|
| Excel (desktop) | Yes | No — documented only | n/a |
| Excel for the web | — | Yes (recalc, 2026-09-01) | Supported, behaves as documented |
| Google Sheets | Yes | Yes (Drive import, 2026-08-31) | Supported, behaves as documented |
| LibreOffice Calc | Yes | Yes (25.8.7.3, 2026-08-31) | Quirk found |
LibreOffice version history
We executed the same test cases under each LibreOffice release to show exactly when COT’s support changed — not documentation claims, real results.
| LibreOffice version | Verdict | Tested |
|---|---|---|
| 24.2.0.3 | Quirk found | 2026-08-31 |
| 24.8.7.2 | Quirk found | 2026-08-31 |
| 25.2.0.3 | Quirk found | 2026-08-31 |
| 25.8.7.3 | Quirk found | 2026-08-31 |
Why isn't COT working in LibreOffice?
COT exists in LibreOffice 25.8.7.3, but it is not a drop-in match for
Excel — our executed tests found real behavioral differences (detailed in the test results on this
page). If a formula that works in Excel or Google Sheets misbehaves in LibreOffice, compare your usage
against the failing cases above before assuming your data is wrong.
Discovered quirks
-
=COT(0) on
LibreOffice Calc returned
#NUM!, but the documented/expected
result is #DIV/0!.
Provenance
Excel documents: "COT(0) returns the #DIV/0! error value." This follows from the documented identity COT(n) = 1/TAN(n) with TAN(0) = 0, and is a different error class from the #NUM! the same page specifies for out-of-range arguments. EXECUTED RESULT: all four LibreOffice builds return #NUM! here, i.e. they collapse the two documented error classes onto the out-of-range one; MISMATCH vs expected: expected '#DIV/0!', got '#NUM!'
-
=COT(2^27) on
LibreOffice Calc returned
-0.846108835418734, but the documented/expected
result is #NUM!.
Provenance
Excel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, COT returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. EXECUTED RESULT: all four LibreOffice builds ignore this range check and return -0.846108835418734 instead of the documented error -- and that number is not garbage: cot(2^27) re-derived with mpmath at 60 digits is -0.84610883541873383485, so LibreOffice's argument reduction is accurate to full double precision here and it simply declines to refuse an input Excel refuses; MISMATCH vs expected: expected '#NUM!', got -0.846108835418734
Executed test cases
Excel for the web (executed 2026-09-01 via OneDrive recalculation)
These values come from Excel for the web, not from desktop Excel. They are two different implementations of the calculation engine, and this run measured only the web one: the corpus was uploaded to OneDrive as .xlsx, recalculated by Excel for the web on open, and downloaded again for readback. Excel for the web is a rolling service with no pinnable version, so the run is identified by its date. Where a value here disagrees with the Expected column — which is Microsoft’s documentation of the desktop product — we cannot tell you whether the web engine diverges from the desktop one or the documentation is wrong about both, because we do not run desktop Excel.
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =ROUND(COT(30),9) | Microsoft's documented worked example: the cotangent of 30 radians | -0.156119952 | -0.156119952ProvenanceMicrosoft's page publishes this example's result to three decimals as -0.156. Independently derived from the documented identity COT(n) = 1/TAN(n): 1/math.tan(30) = -0.15611995216165922 -> -0.156119952 at 9 dp, which agrees with the published -0.156 at the depth the page prints. Asserted at 9 dp because the deeper figure is derived rather than copied. Note the argument is 30 RADIANS, not 30 degrees, which is why the value is negative |
Matched |
| =ROUND(COT(A5),9) | Microsoft's documented worked example: the cotangent of the value 45 held in a cell | 0.617369624 | 0.617369624ProvenanceMicrosoft's page publishes this example's result to three decimals as 0.617. Independently derived: 1/math.tan(45) = 0.6173696237835551 -> 0.617369624 at 9 dp, which agrees with the published 0.617 |
Matched |
| =COT(0) | The cotangent at zero | #DIV/0! | #DIV/0!ProvenanceExcel documents: "COT(0) returns the #DIV/0! error value." This follows from the documented identity COT(n) = 1/TAN(n) with TAN(0) = 0, and is a different error class from the #NUM! the same page specifies for out-of-range arguments. EXECUTED RESULT: all four LibreOffice builds return #NUM! here, i.e. they collapse the two documented error classes onto the out-of-range one |
Matched |
| =COT(2^27) | An argument at the documented magnitude limit of 2^27 | #NUM! | #NUM!ProvenanceExcel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, COT returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. EXECUTED RESULT: all four LibreOffice builds ignore this range check and return -0.846108835418734 instead of the documented error -- and that number is not garbage: cot(2^27) re-derived with mpmath at 60 digits is -0.84610883541873383485, so LibreOffice's argument reduction is accurate to full double precision here and it simply declines to refuse an input Excel refuses |
Matched |
| =COT("abc") | A non-numeric argument | #VALUE! | #VALUE!ProvenanceExcel documents: "If Number is a non-numeric value, COT returns the #VALUE! error value." |
Matched |
Google Sheets (executed 2026-08-31 via Drive import)
Google Sheets is a rolling service with no pinnable version, so this run is identified by its date. The corpus was imported to Drive as .xlsx, recalculated by Sheets, and exported back for readback.
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =ROUND(COT(30),9) | Microsoft's documented worked example: the cotangent of 30 radians | -0.156119952 | -0.156119952ProvenanceMicrosoft's page publishes this example's result to three decimals as -0.156. Independently derived from the documented identity COT(n) = 1/TAN(n): 1/math.tan(30) = -0.15611995216165922 -> -0.156119952 at 9 dp, which agrees with the published -0.156 at the depth the page prints. Asserted at 9 dp because the deeper figure is derived rather than copied. Note the argument is 30 RADIANS, not 30 degrees, which is why the value is negative |
Matched |
| =ROUND(COT(A5),9) | Microsoft's documented worked example: the cotangent of the value 45 held in a cell | 0.617369624 | 0.617369624ProvenanceMicrosoft's page publishes this example's result to three decimals as 0.617. Independently derived: 1/math.tan(45) = 0.6173696237835551 -> 0.617369624 at 9 dp, which agrees with the published 0.617 |
Matched |
| =COT(0) | The cotangent at zero | #DIV/0! | #DIV/0!ProvenanceExcel documents: "COT(0) returns the #DIV/0! error value." This follows from the documented identity COT(n) = 1/TAN(n) with TAN(0) = 0, and is a different error class from the #NUM! the same page specifies for out-of-range arguments. EXECUTED RESULT: all four LibreOffice builds return #NUM! here, i.e. they collapse the two documented error classes onto the out-of-range one |
Matched |
| =COT(2^27) | An argument at the documented magnitude limit of 2^27 | #NUM! | #NUM!ProvenanceExcel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, COT returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. EXECUTED RESULT: all four LibreOffice builds ignore this range check and return -0.846108835418734 instead of the documented error -- and that number is not garbage: cot(2^27) re-derived with mpmath at 60 digits is -0.84610883541873383485, so LibreOffice's argument reduction is accurate to full double precision here and it simply declines to refuse an input Excel refuses |
Matched |
| =COT("abc") | A non-numeric argument | #VALUE! | #VALUE!ProvenanceExcel documents: "If Number is a non-numeric value, COT returns the #VALUE! error value." |
Matched |
LibreOffice Calc 25.8.7.3 (tested 2026-08-31)
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =ROUND(COT(30),9) | Microsoft's documented worked example: the cotangent of 30 radians | -0.156119952 | -0.156119952ProvenanceMicrosoft's page publishes this example's result to three decimals as -0.156. Independently derived from the documented identity COT(n) = 1/TAN(n): 1/math.tan(30) = -0.15611995216165922 -> -0.156119952 at 9 dp, which agrees with the published -0.156 at the depth the page prints. Asserted at 9 dp because the deeper figure is derived rather than copied. Note the argument is 30 RADIANS, not 30 degrees, which is why the value is negative |
Matched |
| =ROUND(COT(A5),9) | Microsoft's documented worked example: the cotangent of the value 45 held in a cell | 0.617369624 | 0.617369624ProvenanceMicrosoft's page publishes this example's result to three decimals as 0.617. Independently derived: 1/math.tan(45) = 0.6173696237835551 -> 0.617369624 at 9 dp, which agrees with the published 0.617 |
Matched |
| =COT(0) | The cotangent at zero | #NUM! | #DIV/0!ProvenanceExcel documents: "COT(0) returns the #DIV/0! error value." This follows from the documented identity COT(n) = 1/TAN(n) with TAN(0) = 0, and is a different error class from the #NUM! the same page specifies for out-of-range arguments. EXECUTED RESULT: all four LibreOffice builds return #NUM! here, i.e. they collapse the two documented error classes onto the out-of-range one |
Mismatch |
| =COT(2^27) | An argument at the documented magnitude limit of 2^27 | -0.846108835418734 | #NUM!ProvenanceExcel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, COT returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. EXECUTED RESULT: all four LibreOffice builds ignore this range check and return -0.846108835418734 instead of the documented error -- and that number is not garbage: cot(2^27) re-derived with mpmath at 60 digits is -0.84610883541873383485, so LibreOffice's argument reduction is accurate to full double precision here and it simply declines to refuse an input Excel refuses |
Mismatch |
| =COT("abc") | A non-numeric argument | #VALUE! | #VALUE!ProvenanceExcel documents: "If Number is a non-numeric value, COT returns the #VALUE! error value." |
Matched |
Docs & syntax
- Excel (desktop): official documentation
- Google Sheets: official documentation
- LibreOffice Calc: official documentation
Where COT behaves differently
- Every error code LibreOffice reports as #VALUE!
Across our 2,334-case executed corpus, 272 cases in 135 functions return #VALUE! in LibreOffice Calc 25.8.7.3 where Microsoft documents #NUM! (244), #N/A (15), #DIV/0! (10) or #REF! (3). Google Sheets returns the documented code on 239 of the 249 it has a function for. Identical in all four LibreOffice builds tested. - Your function exists but your file cannot say so: _xlfn storage tokens
Executed: eight IM* functions LibreOffice implements return #NAME? on all four builds because it cannot read Excel's _xlfn. token for them, while COT and CSC only work under that same prefix. Eleven LibreOffice aliases are erased by its own exporter, and a token change between 24.2 and 24.8 makes a 24.8-written file open as #NAME? in 24.2.