LOG

What it does

LOG(number, [base])

LOG(number, [base]) returns the logarithm of number to the given base: the power to which the base must be raised to obtain the number. Microsoft's own gloss of the first example is exactly that — "the power to which the base must be raised to equal 10."

LOG(x, b) = log_b x = ln x / ln b

The change-of-base identity in the second form is not one implementation choice among many; it is the definition of a logarithm to an arbitrary base once the natural logarithm exists. Every other property follows:

• Domain. x > 0 and b > 0 with b ≠ 1. The base must be positive because b^y is not real-valued for negative b at fractional y, and it must differ from 1 because 1^y is 1 for every y — there is no power of 1 that gives 2, and log₁ is not a function.
• Range. All of ℝ.
• The pole in the base. As b → 1, ln b → 0 and the quotient diverges. This is a genuine pole of the two-variable function, and it is the numerical hazard specific to LOG — see "Numerical notes".
• Monotonicity flips. For b > 1 the function increases in x; for 0 < b < 1 it decreases. log_b x and log_{1/b} x are negatives of one another.
• Fixed points. LOG(b, b) = 1 and LOG(1, b) = 0 for every admissible base.

Microsoft's three documented examples cover the shape: base omitted gives base 10, an integer base gives the expected integer answer for an exact power, and a base of approximately e reproduces the natural logarithm.

Arguments

The declared arity is one to two, matching. Both slots are numeric and subject to ordinary to-number coercion (coercion and lifting).

The default is 10, not e. This is the one thing about LOG that costs people real money: in most programming languages and in most mathematical writing outside engineering, an unadorned log means the natural logarithm. In Excel it means base 10. A formula ported from Python, R, C or MATLAB that reads LOG(x) is wrong by a constant factor of ln 10 ≈ 2.302585…, and it is wrong quietly, because the result is still a plausible number. The Excel spelling of the natural logarithm is LN.

Try it

Quirks

Result and edge cases

Returns Number.

• Zero and negative first arguments produce #NUM!.
• LOG(TRUE) converts the logical to 1 and returns zero. Undocumented conversion.
• Numeric text converts and evaluates.
• The largest finite double and the smallest positive subnormal produce finite results, both host-scoped.
• An inline array in the first slot lifts elementwise.
• An empty range produces #VALUE!.

The battery does not probe the base argument at all — every row exercises the default. The whole of LOG's distinctive behaviour therefore sits outside the published battery, which is worth knowing before drawing any conclusion from it.

How to implement

Numerical notes

LOG is the clearest case in the math category of a function whose difficulty is not in its kernel. The kernel is LN, and its analysis belongs on that page. What belongs here is what the division does.

Two logarithms and a divide. If each ln is correctly rounded to within half an ULP and the division adds another half, the quotient carries about 1.5 ULP of error in the best case — before any conditioning is considered. That is why a dedicated log10 (which folds the 1/ln10 scaling into the polynomial) beats ln(x)/ln(10), and it is the reason the upstream claim of special-casing was plausible enough to be believed for a while. On the sweep's finding Excel does not take the more accurate route, which means a compatibility implementation must reproduce the quotient, including its extra rounding, rather than improve on it. This is one of the recurring shapes in this Handbook: matching Excel and being accurate are different objectives, and here they point in different directions.

The base-near-1 pole is the real hazard. The condition number of the quotient with respect to the base is proportional to 1/ln b. As b → 1 the denominator goes to zero, so the relative error in the result is amplified without bound:

• At b = 1.0001, ln b is about 10⁻⁴, and every ULP of error in the denominator is amplified by four orders of magnitude in the answer.
• Worse, ln b for b near 1 is itself the ln(1+x) cancellation problem described on the LN page: the base as a double has already lost the low bits of b − 1.

So LOG(x, 1.0000001) is a compounded disaster — an inaccurate denominator, divided into, amplified. There is a correct way to compute it (evaluate the denominator as log1p(b-1) from the exact perturbation, which needs the perturbation rather than the perturbed value), and there is no way to reach it from the worksheet, because Excel publishes no log1p. A reader whose base is near 1 — a growth rate, a per-period interest factor — should restructure the formula rather than trust the function. The honest statement is that this is a domain where the mathematics is ill-conditioned, not a domain where any implementation is at fault.

Argument reduction and the kernel are LN's, and the substrate identification, the ruled-out libm list and the host-CPU caveat on the last bit all carry across from the same evidence record. For the standard treatment of the underlying kernel see Cody & Waite, Software Manual for the Elementary Functions, and Muller, Elementary Functions; Abramowitz & Stegun chapter 4, section 4.1 tabulates the change-of-base relations.

Rust code

27 log "LOG" (1, 2) [V "number", V "base"] |s, a, sv| {
    // Omitting the base selects the decimal logarithm; a base left empty is 0.
    let x = num(s, a, 0)?;
    if a.len() == 1 {
        out(s, k::log10_fn::log10_kernel(x))
    } else {
        let base = num(s, a, 1)?;
        out(s, k::log_fn::log_kernel(x, base))
    }
}

pub fn log_kernel(number: f64, base: f64) -> Result<f64, WorksheetErrorCode> {
    if number <= 0.0 || base <= 0.0 {
        return Err(WorksheetErrorCode::Num);
    }
    if base == 1.0 {
        return Err(WorksheetErrorCode::Div0);
    }
    // The observed explicit-base LOG graph is a staged quotient of two stored logarithms.
    // (both `ln`s are the x87 backend). This was confirmed by a live-Excel sweep
    // of 218 rows across bases 2, 10, and arbitrary — all bit-exact, including
    // Excel's own imprecision (e.g. LOG(1000,10) = 2.9999999999999996, NOT 3).
    // Do NOT special-case base 2 or 10 to a dedicated log2/log10: Excel's
    // dedicated LOG10() worksheet function returns an exact 3 for LOG10(1000),
    // but LOG(1000,10) differs. W111's paired capture also distinguishes omitted
    // LOG(1000), which agrees with LOG10 and is selected in the surface below.
    let value = crate::ported::excel_numeric::excel_x87_div(
        crate::ported::excel_numeric::excel_log(number),
        crate::ported::excel_numeric::excel_log(base),
    );
    // W111: LOG(1, base<1) publishes positive zero. The neighboring-one
    // discriminator also distinguishes the staged divide from native division.
    Ok(if value == 0.0 { 0.0 } else { value })
}

No implementation has been published with a Handbook test suite for this function.

Version differences

The recorded environments below distinguish a reading from a same-input comparison. Counts describe captured inputs in each environment; overlapping captures and comparisons are not totals of unique worksheet calls.

• XC-LOG-001: build 19929 versus build 20430; 3 same-input pairs, 0 differing answers. Compared axes: excel-build. Numeric answers were compared by their recorded binary64 bits; other answers by typed value.

Agreement on these compared inputs does not establish agreement on unmeasured inputs.

Recorded environments and comparison details.

Alternatives

Relationships

• LN — the natural logarithm, and (on the upstream finding below) the routine LOG calls twice. LOG(x, EXP(1)) and LN(x) are the same value mathematically; whether they agree in the last bit is a different question and is not settled here.
• POWER and ^ — the inverse relation: POWER(b, LOG(x, b)) is x, up to rounding.
• IMLOG10 / IMLOG2 — the complex-valued counterparts. Excel publishes a complex base-2 logarithm but no real one: there is no LOG2. Base 2 on the worksheet goes through LOG(x, 2), which is exactly the case the finding below is about.

A retracted upstream claim, recorded here because it is instructive. One of the reference engine's own documents asserted that Excel special-cases base 10 and base 2, using dedicated log10/log2 routines that are more accurate than the naive quotient. The live-Excel sweep behind this page's evidence record refuted that: on the sweep's own finding, LOG(x, base) is ln(x)/ln(base) for every base, and the special-casing was removed. The two upstream documents contradict each other and the record carries the retraction explicitly. The Handbook publishes both sides rather than silently preferring one, and notes that the refuting evidence is the more recent and the more direct.

Named variants

No named variants are recorded yet.