IMCOTH
Unsupported (not recognized)Category: Engineering · Last tested 2026-09-01
Real compatibility results for the IMCOTH function: executed in Excel for the web, Google Sheets and LibreOffice Calc, measured against Google’s published documentation. Excel does not document IMCOTH, so this page makes no claim about Excel. Syntax and links to that documentation are below.
Support matrix
| Engine | Documented | Live-tested | Verdict |
|---|---|---|---|
| Excel (desktop) | No | n/a (not an Excel function) | n/a |
| Excel for the web | — | Yes (recalc, 2026-09-01) | Unsupported (not recognized) |
| Google Sheets | Yes | Yes (Drive import, 2026-09-01) | Supported, behaves as documented |
| LibreOffice Calc | No | Yes (25.8.7.3, 2026-09-01) | Unsupported (not recognized) |
LibreOffice version history
We executed the same test cases under each LibreOffice release to show exactly when IMCOTH’s support changed — not documentation claims, real results.
| LibreOffice version | Verdict | Tested |
|---|---|---|
| 24.2.0.3 | Unsupported (not recognized) | 2026-09-01 |
| 24.8.7.2 | Unsupported (not recognized) | 2026-09-01 |
| 25.2.0.3 | Unsupported (not recognized) | 2026-09-01 |
| 25.8.7.3 | Unsupported (not recognized) | 2026-09-01 |
Why isn't IMCOTH working in LibreOffice?
LibreOffice Calc does not implement IMCOTH as of 25.8.7.3 — in our
executed tests it returns a #NAME? (unrecognized function) error. This is not a typo or a
settings problem, and saving the file as .xlsx does not change it: the function simply isn’t
available yet.
Watch the LibreOffice version support page —
we re-run every test on each new release, so it will flip to Supported here as soon as it lands.
Discovered quirks
-
=IMCOTH(COMPLEX(4,1)) on
Excel for the web returned
#NAME?, but the documented/expected
result is 0.999720649533931-0.000609900253822228i.
Provenance
GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table in the article body: =IMCOTH(COMPLEX(4,1)) -> 0.999720649533931-0.000609900253822228i. Derived independently as coth(4+i) = 0.999720649533930749036738985046491656585 - 0.0006099002538222275728563166231837522767836i, which rounds to the published 15 significant digits exactly. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '0.999720649533931-0.000609900253822228i', got '#NAME?'
-
=ROUND(IMCOTH(3.5),14) on
Excel for the web returned
#NAME?, but the documented/expected
result is 1.00182542850644.
Provenance
GOOGLE'S OWN PUBLISHED RESULT: =IMCOTH(3.5) -> 1.00182542850644. Derived independently as coth(3.5) = 1.001825428506443467329849802769891235631. ROUND-wrapped at 14 places, which is where the published figure ends. The `number` argument description is what licenses a bare real here: "a real number interpreted as a complex number with imaginary parts equal to 0". Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 1.00182542850644, got '#NAME?'
-
=ROUND(IMREAL(IMCOTH("3+2i")),15) on
Excel for the web returned
#NAME?, but the documented/expected
result is 0.996757796569358.
Provenance
GOOGLE'S OWN PUBLISHED RESULT: =IMCOTH("3+2i") -> 0.996757796569358+0.00373971037633696i. This case asserts the REAL part of that value, taken through IMREAL so that a formatting difference cannot be mistaken for a numerical one. Derived independently as Re coth(3+2i) = 0.996757796569358310460968797117470718332. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 0.996757796569358, got '#NAME?'
-
=ROUND(IMAGINARY(IMCOTH("3+2i")),17) on
Excel for the web returned
#NAME?, but the documented/expected
result is 0.00373971037633696.
Provenance
The imaginary half of the same published result, 0.00373971037633696, derived independently as Im coth(3+2i) = 0.003739710376336956660117408691902576240006. Rounded at 17 decimal places, which is 15 significant digits for a number of this size. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 0.00373971037633696, got '#NAME?'
-
=ROUND(IMABS(IMSUB(IMCOTH("3+2i"),IMDIV(1,IMTANH("3+2i")))),12) on
Excel for the web returned
#NAME?, but the documented/expected
result is 0.
Provenance
A STRUCTURAL assertion with no derived constant. The page defines the function only by name -- "returns the hyperbolic cotangent of the given complex number" -- and its sibling page defines IMTANH as the hyperbolic tangent; coth = 1/tanh is what those two names mean, so the two spellings must agree in the same engine whatever either computes. Compared through IMABS of the difference, because complex results are strings and cannot be subtracted with `-`. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected 0, got '#NAME?'
-
=IMCOTH(COMPLEX(4,1)) on
LibreOffice Calc returned
#NAME?, but the documented/expected
result is 0.999720649533931-0.000609900253822228i.
Provenance
GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table in the article body: =IMCOTH(COMPLEX(4,1)) -> 0.999720649533931-0.000609900253822228i. Derived independently as coth(4+i) = 0.999720649533930749036738985046491656585 - 0.0006099002538222275728563166231837522767836i, which rounds to the published 15 significant digits exactly. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '0.999720649533931-0.000609900253822228i', got '#NAME?'
-
=ROUND(IMCOTH(3.5),14) on
LibreOffice Calc returned
#NAME?, but the documented/expected
result is 1.00182542850644.
Provenance
GOOGLE'S OWN PUBLISHED RESULT: =IMCOTH(3.5) -> 1.00182542850644. Derived independently as coth(3.5) = 1.001825428506443467329849802769891235631. ROUND-wrapped at 14 places, which is where the published figure ends. The `number` argument description is what licenses a bare real here: "a real number interpreted as a complex number with imaginary parts equal to 0". Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 1.00182542850644, got '#NAME?'
-
=ROUND(IMREAL(IMCOTH("3+2i")),15) on
LibreOffice Calc returned
#NAME?, but the documented/expected
result is 0.996757796569358.
Provenance
GOOGLE'S OWN PUBLISHED RESULT: =IMCOTH("3+2i") -> 0.996757796569358+0.00373971037633696i. This case asserts the REAL part of that value, taken through IMREAL so that a formatting difference cannot be mistaken for a numerical one. Derived independently as Re coth(3+2i) = 0.996757796569358310460968797117470718332. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 0.996757796569358, got '#NAME?'
-
=ROUND(IMAGINARY(IMCOTH("3+2i")),17) on
LibreOffice Calc returned
#NAME?, but the documented/expected
result is 0.00373971037633696.
Provenance
The imaginary half of the same published result, 0.00373971037633696, derived independently as Im coth(3+2i) = 0.003739710376336956660117408691902576240006. Rounded at 17 decimal places, which is 15 significant digits for a number of this size. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 0.00373971037633696, got '#NAME?'
-
=ROUND(IMABS(IMSUB(IMCOTH("3+2i"),IMDIV(1,IMTANH("3+2i")))),12) on
LibreOffice Calc returned
#NAME?, but the documented/expected
result is 0.
Provenance
A STRUCTURAL assertion with no derived constant. The page defines the function only by name -- "returns the hyperbolic cotangent of the given complex number" -- and its sibling page defines IMTANH as the hyperbolic tangent; coth = 1/tanh is what those two names mean, so the two spellings must agree in the same engine whatever either computes. Compared through IMABS of the difference, because complex results are strings and cannot be subtracted with `-`. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected 0, got '#NAME?'
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 |
|---|---|---|---|---|
| =IMCOTH(COMPLEX(4,1)) | Published row 1, asserted as the exact result string Google prints | #NAME? | 0.999720649533931-0.000609900253822228iProvenanceGOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table in the article body: =IMCOTH(COMPLEX(4,1)) -> 0.999720649533931-0.000609900253822228i. Derived independently as coth(4+i) = 0.999720649533930749036738985046491656585 - 0.0006099002538222275728563166231837522767836i, which rounds to the published 15 significant digits exactly. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. |
Mismatch |
| =ROUND(IMCOTH(3.5),14) | Published row 2: a real argument, which the page says is read as a complex number | #NAME? | 1.00182542850644ProvenanceGOOGLE'S OWN PUBLISHED RESULT: =IMCOTH(3.5) -> 1.00182542850644. Derived independently as coth(3.5) = 1.001825428506443467329849802769891235631. ROUND-wrapped at 14 places, which is where the published figure ends. The `number` argument description is what licenses a bare real here: "a real number interpreted as a complex number with imaginary parts equal to 0". Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. |
Mismatch |
| =ROUND(IMREAL(IMCOTH("3+2i")),15) | Published row 3, real part, from a string-form argument | #NAME? | 0.996757796569358ProvenanceGOOGLE'S OWN PUBLISHED RESULT: =IMCOTH("3+2i") -> 0.996757796569358+0.00373971037633696i. This case asserts the REAL part of that value, taken through IMREAL so that a formatting difference cannot be mistaken for a numerical one. Derived independently as Re coth(3+2i) = 0.996757796569358310460968797117470718332. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. |
Mismatch |
| =ROUND(IMAGINARY(IMCOTH("3+2i")),17) | The imaginary part of the same published row | #NAME? | 0.00373971037633696ProvenanceThe imaginary half of the same published result, 0.00373971037633696, derived independently as Im coth(3+2i) = 0.003739710376336956660117408691902576240006. Rounded at 17 decimal places, which is 15 significant digits for a number of this size. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. |
Mismatch |
| =ROUND(IMABS(IMSUB(IMCOTH("3+2i"),IMDIV(1,IMTANH("3+2i")))),12) | The hyperbolic cotangent against the reciprocal of the hyperbolic tangent | #NAME? | 0ProvenanceA STRUCTURAL assertion with no derived constant. The page defines the function only by name -- "returns the hyperbolic cotangent of the given complex number" -- and its sibling page defines IMTANH as the hyperbolic tangent; coth = 1/tanh is what those two names mean, so the two spellings must agree in the same engine whatever either computes. Compared through IMABS of the difference, because complex results are strings and cannot be subtracted with `-`. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655. |
Mismatch |
Google Sheets (executed 2026-09-01 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 |
|---|---|---|---|---|
| =IMCOTH(COMPLEX(4,1)) | Published row 1, asserted as the exact result string Google prints | 0.999720649533931-0.000609900253822228i | 0.999720649533931-0.000609900253822228iProvenanceGOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table in the article body: =IMCOTH(COMPLEX(4,1)) -> 0.999720649533931-0.000609900253822228i. Derived independently as coth(4+i) = 0.999720649533930749036738985046491656585 - 0.0006099002538222275728563166231837522767836i, which rounds to the published 15 significant digits exactly. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. |
Matched |
| =ROUND(IMCOTH(3.5),14) | Published row 2: a real argument, which the page says is read as a complex number | 1.001825429 | 1.00182542850644ProvenanceGOOGLE'S OWN PUBLISHED RESULT: =IMCOTH(3.5) -> 1.00182542850644. Derived independently as coth(3.5) = 1.001825428506443467329849802769891235631. ROUND-wrapped at 14 places, which is where the published figure ends. The `number` argument description is what licenses a bare real here: "a real number interpreted as a complex number with imaginary parts equal to 0". Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. |
Matched |
| =ROUND(IMREAL(IMCOTH("3+2i")),15) | Published row 3, real part, from a string-form argument | 0.9967577966 | 0.996757796569358ProvenanceGOOGLE'S OWN PUBLISHED RESULT: =IMCOTH("3+2i") -> 0.996757796569358+0.00373971037633696i. This case asserts the REAL part of that value, taken through IMREAL so that a formatting difference cannot be mistaken for a numerical one. Derived independently as Re coth(3+2i) = 0.996757796569358310460968797117470718332. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. |
Matched |
| =ROUND(IMAGINARY(IMCOTH("3+2i")),17) | The imaginary part of the same published row | 0.003739710376 | 0.00373971037633696ProvenanceThe imaginary half of the same published result, 0.00373971037633696, derived independently as Im coth(3+2i) = 0.003739710376336956660117408691902576240006. Rounded at 17 decimal places, which is 15 significant digits for a number of this size. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. |
Matched |
| =ROUND(IMABS(IMSUB(IMCOTH("3+2i"),IMDIV(1,IMTANH("3+2i")))),12) | The hyperbolic cotangent against the reciprocal of the hyperbolic tangent | 0 | 0ProvenanceA STRUCTURAL assertion with no derived constant. The page defines the function only by name -- "returns the hyperbolic cotangent of the given complex number" -- and its sibling page defines IMTANH as the hyperbolic tangent; coth = 1/tanh is what those two names mean, so the two spellings must agree in the same engine whatever either computes. Compared through IMABS of the difference, because complex results are strings and cannot be subtracted with `-`. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655. |
Matched |
LibreOffice Calc 25.8.7.3 (tested 2026-09-01)
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =IMCOTH(COMPLEX(4,1)) | Published row 1, asserted as the exact result string Google prints | #NAME? | 0.999720649533931-0.000609900253822228iProvenanceGOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table in the article body: =IMCOTH(COMPLEX(4,1)) -> 0.999720649533931-0.000609900253822228i. Derived independently as coth(4+i) = 0.999720649533930749036738985046491656585 - 0.0006099002538222275728563166231837522767836i, which rounds to the published 15 significant digits exactly. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. |
Mismatch |
| =ROUND(IMCOTH(3.5),14) | Published row 2: a real argument, which the page says is read as a complex number | #NAME? | 1.00182542850644ProvenanceGOOGLE'S OWN PUBLISHED RESULT: =IMCOTH(3.5) -> 1.00182542850644. Derived independently as coth(3.5) = 1.001825428506443467329849802769891235631. ROUND-wrapped at 14 places, which is where the published figure ends. The `number` argument description is what licenses a bare real here: "a real number interpreted as a complex number with imaginary parts equal to 0". Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. |
Mismatch |
| =ROUND(IMREAL(IMCOTH("3+2i")),15) | Published row 3, real part, from a string-form argument | #NAME? | 0.996757796569358ProvenanceGOOGLE'S OWN PUBLISHED RESULT: =IMCOTH("3+2i") -> 0.996757796569358+0.00373971037633696i. This case asserts the REAL part of that value, taken through IMREAL so that a formatting difference cannot be mistaken for a numerical one. Derived independently as Re coth(3+2i) = 0.996757796569358310460968797117470718332. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. |
Mismatch |
| =ROUND(IMAGINARY(IMCOTH("3+2i")),17) | The imaginary part of the same published row | #NAME? | 0.00373971037633696ProvenanceThe imaginary half of the same published result, 0.00373971037633696, derived independently as Im coth(3+2i) = 0.003739710376336956660117408691902576240006. Rounded at 17 decimal places, which is 15 significant digits for a number of this size. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. |
Mismatch |
| =ROUND(IMABS(IMSUB(IMCOTH("3+2i"),IMDIV(1,IMTANH("3+2i")))),12) | The hyperbolic cotangent against the reciprocal of the hyperbolic tangent | #NAME? | 0ProvenanceA STRUCTURAL assertion with no derived constant. The page defines the function only by name -- "returns the hyperbolic cotangent of the given complex number" -- and its sibling page defines IMTANH as the hyperbolic tangent; coth = 1/tanh is what those two names mean, so the two spellings must agree in the same engine whatever either computes. Compared through IMABS of the difference, because complex results are strings and cannot be subtracted with `-`. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655. |
Mismatch |
Docs & syntax
- Google Sheets: official documentation