IMLOG

TYPE CORRECTION (2026-09-01, post-ingest): first authored as the number 2; the executed engine returns the TEXT string '2' -- like every IM* function, IMLOG returns complex results as text, and Google's published table prints the figure typelessly. The expected is now the string, matching the engine's actual (and documented-family-consistent) return type; the printed figure itself was never in dispute. GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(100, 10) -> 2. IMLOG's page is the only one of the three complex pages in this batch whose Sample-formulas inputs and Formula/Result table rows MATCH each other, so its three published results can be paired with its three samples directly. 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. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486. 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.

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim: =IMLOG("1+i", 3.5) -> 0.276647377832556+0.626932774314643i. Derived independently as log(1+i)/log(3.5) = 0.2766473778325561086024443610317785858615 + 0.6269327743146426385843035649172255217738i. NOTE THAT THE PAGE NEVER STATES A BRANCH: there is no sentence about the principal value or the branch cut of the complex logarithm anywhere on it, so this case asserts the published value and the corpus asserts nothing about arguments where the branch would matter. 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 IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(COMPLEX(25, 34), 2.3) -> 4.49324546771284+1.12470086031758i. Real part derived independently as 4.493245467712837686199121881993797704048. The base argument is the only one the page constrains: "Must be a positive real number." No default is stated and the page presents base as required. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

The imaginary half of the same published result, derived independently as 1.124700860317582465513509687755013399277. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

A structural assertion with no derived constant. The Notes bullet reads: "IMLOG is equivalent to LOG for all non-complex values that are greater than zero." Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

A structural assertion with no derived constant, from the Notes bullet "IMLOG is equivalent to IMLOG2 given base of 2." Asserted on "1+i" rather than a real, because that is where the two implementations could differ without any published example noticing. Compared through IMABS of the difference, since complex results are strings. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

TYPE CORRECTION (2026-09-01, post-ingest): first authored as the number 2; the executed engine returns the TEXT string '2' -- like every IM* function, IMLOG returns complex results as text, and Google's published table prints the figure typelessly. The expected is now the string, matching the engine's actual (and documented-family-consistent) return type; the printed figure itself was never in dispute. GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(100, 10) -> 2. IMLOG's page is the only one of the three complex pages in this batch whose Sample-formulas inputs and Formula/Result table rows MATCH each other, so its three published results can be paired with its three samples directly. 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. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486. 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.

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim: =IMLOG("1+i", 3.5) -> 0.276647377832556+0.626932774314643i. Derived independently as log(1+i)/log(3.5) = 0.2766473778325561086024443610317785858615 + 0.6269327743146426385843035649172255217738i. NOTE THAT THE PAGE NEVER STATES A BRANCH: there is no sentence about the principal value or the branch cut of the complex logarithm anywhere on it, so this case asserts the published value and the corpus asserts nothing about arguments where the branch would matter. 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 IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(COMPLEX(25, 34), 2.3) -> 4.49324546771284+1.12470086031758i. Real part derived independently as 4.493245467712837686199121881993797704048. The base argument is the only one the page constrains: "Must be a positive real number." No default is stated and the page presents base as required. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

The imaginary half of the same published result, derived independently as 1.124700860317582465513509687755013399277. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

A structural assertion with no derived constant. The Notes bullet reads: "IMLOG is equivalent to LOG for all non-complex values that are greater than zero." Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

A structural assertion with no derived constant, from the Notes bullet "IMLOG is equivalent to IMLOG2 given base of 2." Asserted on "1+i" rather than a real, because that is where the two implementations could differ without any published example noticing. Compared through IMABS of the difference, since complex results are strings. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

TYPE CORRECTION (2026-09-01, post-ingest): first authored as the number 2; the executed engine returns the TEXT string '2' -- like every IM* function, IMLOG returns complex results as text, and Google's published table prints the figure typelessly. The expected is now the string, matching the engine's actual (and documented-family-consistent) return type; the printed figure itself was never in dispute. GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(100, 10) -> 2. IMLOG's page is the only one of the three complex pages in this batch whose Sample-formulas inputs and Formula/Result table rows MATCH each other, so its three published results can be paired with its three samples directly. 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. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486. 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.

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim: =IMLOG("1+i", 3.5) -> 0.276647377832556+0.626932774314643i. Derived independently as log(1+i)/log(3.5) = 0.2766473778325561086024443610317785858615 + 0.6269327743146426385843035649172255217738i. NOTE THAT THE PAGE NEVER STATES A BRANCH: there is no sentence about the principal value or the branch cut of the complex logarithm anywhere on it, so this case asserts the published value and the corpus asserts nothing about arguments where the branch would matter. 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 IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(COMPLEX(25, 34), 2.3) -> 4.49324546771284+1.12470086031758i. Real part derived independently as 4.493245467712837686199121881993797704048. The base argument is the only one the page constrains: "Must be a positive real number." No default is stated and the page presents base as required. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

The imaginary half of the same published result, derived independently as 1.124700860317582465513509687755013399277. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

A structural assertion with no derived constant. The Notes bullet reads: "IMLOG is equivalent to LOG for all non-complex values that are greater than zero." Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.

A structural assertion with no derived constant, from the Notes bullet "IMLOG is equivalent to IMLOG2 given base of 2." Asserted on "1+i" rather than a real, because that is where the two implementations could differ without any published example noticing. Compared through IMABS of the difference, since complex results are strings. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.