← All functions

IMTANH

Unsupported (not recognized)

Category: Engineering · Last tested 2026-09-01

Real compatibility results for the IMTANH function: executed in Excel for the web, Google Sheets and LibreOffice Calc, measured against Google’s published documentation. Excel does not document IMTANH, so this page makes no claim about Excel. Syntax and links to that documentation are below.

Support matrix

EngineDocumentedLive-testedVerdict
Excel (desktop)No n/a (not an Excel function) n/a
Excel for the web— Yes (recalc, 2026-09-01) Unsupported (not recognized)
Google SheetsYes Yes (Drive import, 2026-09-01) Supported, behaves as documented
LibreOffice CalcNo 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 IMTANH’s support changed — not documentation claims, real results.

LibreOffice versionVerdictTested
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 IMTANH working in LibreOffice?

LibreOffice Calc does not implement IMTANH 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

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.

FormulaDescriptionResultExpectedVerdict
=IMTANH(COMPLEX(4,1)) Published row 1, asserted as the exact result string Google prints #NAME? 1.00027905623447+0.00061024092137626i
Provenance

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table: =IMTANH(COMPLEX(4,1)) -> 1.00027905623447+0.00061024092137626i. Derived independently as tanh(4+i) = 1.000279056234465568359093202101514584404 + 0.000610240921376259785352673334029321933866i. NOTE THAT THE PAGE'S TWO LISTS DISAGREE ON THEIR INPUTS: the 'Sample formulas' block uses COMPLEX(4,6), 4 and "2+3i", while the Formula/Result table uses COMPLEX(4,1), 3.5 and "3+2i". Only the table's rows carry results, and only those are asserted here. 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 IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655. 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(IMTANH(3.5),15) Published row 2: a real argument read as a complex number #NAME? 0.998177897611199
Provenance

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH(3.5) -> 0.998177897611199. Derived independently as tanh(3.5) = 0.9981778976111987092842733524506117173517. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.

Mismatch
=ROUND(IMREAL(IMTANH("3+2i")),14) Published row 3, real part, from a string-form argument #NAME? 1.00323862735361
Provenance

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH("3+2i") -> 1.00323862735361-0.00376402564150425i. Real part derived independently as 1.003238627353609801446358597821927259808. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.

Mismatch
=ROUND(IMAGINARY(IMTANH("3+2i")),17) The imaginary part of the same row, which is negative #NAME? -0.00376402564150425
Provenance

The imaginary half of the same published result, derived independently as -0.003764025641504248292751221130322690839631. The sign is the point: IMCOTH on the same argument has a POSITIVE imaginary part, so this pair also checks that the two functions are not the same code. 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.

FormulaDescriptionResultExpectedVerdict
=IMTANH(COMPLEX(4,1)) Published row 1, asserted as the exact result string Google prints 1.00027905623447+0.00061024092137626i 1.00027905623447+0.00061024092137626i
Provenance

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table: =IMTANH(COMPLEX(4,1)) -> 1.00027905623447+0.00061024092137626i. Derived independently as tanh(4+i) = 1.000279056234465568359093202101514584404 + 0.000610240921376259785352673334029321933866i. NOTE THAT THE PAGE'S TWO LISTS DISAGREE ON THEIR INPUTS: the 'Sample formulas' block uses COMPLEX(4,6), 4 and "2+3i", while the Formula/Result table uses COMPLEX(4,1), 3.5 and "3+2i". Only the table's rows carry results, and only those are asserted here. 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 IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655. 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(IMTANH(3.5),15) Published row 2: a real argument read as a complex number 0.9981778976 0.998177897611199
Provenance

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH(3.5) -> 0.998177897611199. Derived independently as tanh(3.5) = 0.9981778976111987092842733524506117173517. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.

Matched
=ROUND(IMREAL(IMTANH("3+2i")),14) Published row 3, real part, from a string-form argument 1.003238627 1.00323862735361
Provenance

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH("3+2i") -> 1.00323862735361-0.00376402564150425i. Real part derived independently as 1.003238627353609801446358597821927259808. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.

Matched
=ROUND(IMAGINARY(IMTANH("3+2i")),17) The imaginary part of the same row, which is negative -0.003764025642 -0.00376402564150425
Provenance

The imaginary half of the same published result, derived independently as -0.003764025641504248292751221130322690839631. The sign is the point: IMCOTH on the same argument has a POSITIVE imaginary part, so this pair also checks that the two functions are not the same code. 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)

FormulaDescriptionResultExpectedVerdict
=IMTANH(COMPLEX(4,1)) Published row 1, asserted as the exact result string Google prints #NAME? 1.00027905623447+0.00061024092137626i
Provenance

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table: =IMTANH(COMPLEX(4,1)) -> 1.00027905623447+0.00061024092137626i. Derived independently as tanh(4+i) = 1.000279056234465568359093202101514584404 + 0.000610240921376259785352673334029321933866i. NOTE THAT THE PAGE'S TWO LISTS DISAGREE ON THEIR INPUTS: the 'Sample formulas' block uses COMPLEX(4,6), 4 and "2+3i", while the Formula/Result table uses COMPLEX(4,1), 3.5 and "3+2i". Only the table's rows carry results, and only those are asserted here. 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 IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655. 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(IMTANH(3.5),15) Published row 2: a real argument read as a complex number #NAME? 0.998177897611199
Provenance

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH(3.5) -> 0.998177897611199. Derived independently as tanh(3.5) = 0.9981778976111987092842733524506117173517. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.

Mismatch
=ROUND(IMREAL(IMTANH("3+2i")),14) Published row 3, real part, from a string-form argument #NAME? 1.00323862735361
Provenance

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH("3+2i") -> 1.00323862735361-0.00376402564150425i. Real part derived independently as 1.003238627353609801446358597821927259808. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.

Mismatch
=ROUND(IMAGINARY(IMTANH("3+2i")),17) The imaginary part of the same row, which is negative #NAME? -0.00376402564150425
Provenance

The imaginary half of the same published result, derived independently as -0.003764025641504248292751221130322690839631. The sign is the point: IMCOTH on the same argument has a POSITIVE imaginary part, so this pair also checks that the two functions are not the same code. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.

Mismatch

Docs & syntax