ILOG Function (Gnumeric)

• Introduced: Gnumeric 1.12.51 release notes explicitly record this function being added.
• Supported in: Gnumeric 1.12.62; no retirement is established.
• Scope: Desktop Gnumeric with the Mathematics plugin. English comma-separated formulas are shown.
• Checked: October 14, 2026. Tables and the named advanced check were recalculated through 1.12.57 ssconvert. Current 1.12.62 source was inspected; the later release was not executed.

ILOG is intended to give the logarithm rounded downward to an integer while avoiding an inaccurate intermediate LOG result near exact powers. The default base is 10. The intended mathematical contract is useful for orders of magnitude, but the tested implementation has the prominent limitation above and does not support every positive base. Versioned function help.

=ILOG(x[,base])

Brackets mark optional arguments; do not type the brackets. Function implementation.

Ordinary results are rounded to twelve decimal places; tiny values use scientific notation. The eight reference rows were independently checked.

For positive whole-number counts, the tested decimal cases distinguish 999 from 1000: their ILOG results are 2 and 3. Adding 1 gives the number of decimal digits for these positive integers. Do not apply that digit-count interpretation to zero or fractions.

For binary capacities, =ILOG(1024,2) returns 10 and =ILOG(1023,2) returns 9. These exponents identify the largest whole power of two no greater than the input. The reference table also tests exact decimal 10^15, where an ordinary logarithm rounded very slightly downward could otherwise lead to an incorrect floor.

Mathematically, log₄(0.125) = −1.5, whose floor is −2. The executed comparison =ILOG(0.125,4)-INT(LOG(0.125,4)) returned 1. In the current source, the power-of-two-base path divides two integers; negative quotients truncate toward zero. This explains the observed discrepancy without treating the returned value as a correct floor.

The comparison with INT(LOG(…)) diagnoses this example; it is not a universally exact replacement at power boundaries. If a workflow depends on fractional inputs and bases such as 4 or 8, verify its cases independently before use. Base 2’s separate native-radix path gave the correct tested −3 for 0.125.

Although the help mentions #VALUE! for unimplemented arguments, the actual tested noninteger bases 0.5 and 1.5 produced #NUM!. The current helper returns a non-number for its unimplemented branch. Both this error discrepancy and the negative-exponent discrepancy are preserved here. Later-version behavior has source evidence only; no 1.12.62 execution is claimed.

F5 is an actually empty cell. Listed errors are native error results, not mathematical zeroes.

• Worksheet implementation
• Numeric helper or conversion source

The retained workbook contained a deliberately stale SUM cache and an uncached SUM formula, both recalculated correctly. Native evidence covers the listed 1.12.57 cases; worksheet layouts and algebraic interpretations are independently specified explanations. Other locales, direct GUI entry and later-release output were not tested.

LOG, LOG2, INT.