LCM

What it does

LCM(number1, [number2], ...)

LCM(number1, [number2], ...) returns the least common multiple of its arguments after each has been truncated to an integer.

For positive integers a, b, lcm(a, b) is the smallest positive integer that both divide. As with gcd, the n-argument function is the associative fold:

lcm(a, b, c) = lcm(lcm(a, b), c)

The structural facts worth carrying:

• lcm(a, 0) = 0, and lcm(a, 1) = a. Zero is the absorbing element of the join, one is its identity — exactly the mirror of gcd, where zero is the identity.
• The two-argument identity gcd(a, b) · lcm(a, b) = a · b holds for non-negative integers. It does not generalize to three or more arguments: the product of gcd and lcm of a triple is not the product of the triple. The correct three-argument identity runs through the inclusion–exclusion of prime exponents, not through a single product, and every attempt to compute a three-way lcm as "product over gcd" is wrong. This is the single most common error in worksheet code that reimplements LCM.
• In prime-exponent form, lcm takes the pointwise maximum of the exponent vectors and gcd the pointwise minimum. That is the whole theory: gcd is the meet, lcm the join, of the divisibility lattice.
• Microsoft's page gives the practical motivation: the least common multiple is what you need to add fractions with unlike denominators.

Domain: non-negative integers after truncation. Range: non-negative integers.

Arguments

Truncation happens before the arithmetic. LCM(2.9, 3) is the lcm of 2 and 3. On the admissible non-negative domain, truncation and floor agree, so the negative-number ambiguity that separates truncation from flooring elsewhere in this category cannot arise here.

Argument slots are numeric and subject to ordinary to-number coercion (coercion and lifting). Range and array arguments are scanned and reduced to a single result; LCM is declared with a custom coercion profile, not the scalar-lift profile, so it does not apply elementwise.

Try it

Quirks

Result and edge cases

Returns Number — a non-negative integer value.

• Zero alone yields zero, consistent with zero as the absorbing element.
• A logical argument is converted and accepted; numeric text is converted and then truncated. Microsoft's page addresses neither case, speaking only of "nonnumeric".
• An inline array is reduced to one result rather than lifted elementwise.
• An empty range produces #VALUE!.
• A subnormal magnitude truncates to zero, and zero absorbs — so a single tiny positive argument turns the whole result into zero. That is mathematically right and practically surprising, and it is the failure mode to watch for when LCM is fed computed values rather than typed constants.

Errors

As documented on Microsoft's LCM page:

Error values in any argument propagate under the shared coercion discipline.

Note the wording of the third row and compare it with GCD's: GCD's ceiling is tested on any parameter, LCM's on the result. The asymmetry is not an editorial accident — a gcd is bounded above by its smallest argument and can never overflow inputs that were themselves admissible, whereas an lcm of two modest coprime arguments is their product and reaches 2^53 quickly. LCM is therefore the member of the pair that must test after computing, which means it must either detect the overflow during the fold or compute in a wider type.

How to implement

Numerical notes

Like GCD, LCM computes exactly in its intended domain — there is no rounding error to analyse — and like GCD its real hazard is representability. Unlike GCD, the hazard is reached from inside the admissible domain, because the lcm of admissible arguments is not itself guaranteed admissible.

Compute in the order that does not overflow. The naive binary step lcm(a, b) = a · b / gcd(a, b) forms the product first, and that product can exceed 2^53 — or exceed the machine word — even when the final answer is comfortably small. The standard remedy is to divide first:

lcm(a, b) = (a / gcd(a, b)) * b

The division is exact because gcd(a, b) divides a, so no precision is lost, and the largest intermediate is the answer itself rather than the product of the inputs. Any implementation that forms a*b before dividing has a smaller usable domain than the one it advertises, and its failures appear as silently wrong values rather than as errors when the arithmetic wraps.

The fold accumulates. With many arguments the running lcm grows monotonically, so an overflow check belongs inside the fold, tested after each step, not once at the end. Checking only the final value cannot detect an intermediate that already wrapped.

The 2^53 wall. Above 2^53 consecutive integers are no longer distinct doubles, so an lcm returned as a binary64 above that point is not the integer it claims to be — it is the nearest representable neighbour, and it may not even be a multiple of the inputs. Microsoft's documented #NUM! is a refusal to hand back a value whose defining property has stopped holding. That is the right instinct, and it is worth stating plainly: above the wall the postcondition fails, not merely the precision.

Knuth, The Art of Computer Programming, volume 2, section 4.5.2 covers the gcd algorithms this function's inner loop rests on; the divide-before-multiply discipline is standard advice in every treatment of exact integer arithmetic.

Rust code

39 lcm "LCM" (1, 255) [R "number1", R "number2"] |s, a, sv| {
    let items = integer_groups(s, a, sv)?;
    out(s, k::lcm_fn::lcm_kernel(&items))
}

pub fn lcm_int(a: i64, b: i64) -> Result<i64, WorksheetErrorCode> {
    if a == 0 || b == 0 {
        Ok(0)
    } else {
        // Each admitted operand is at most 2^53, so the exact product fits
        // u128. Publish its binary64 rounding before checking the next step.
        // In particular, 2^53 + 1 rounds to the admitted boundary 2^53.
        let product = (a / gcd_int(a, b)) as u128 * b as u128;
        let rounded = product as f64;
        if rounded > GCD_LCM_LIMIT {
            Err(WorksheetErrorCode::Num)
        } else {
            Ok(rounded as i64)
        }
    }
}

pub fn lcm_kernel(items: &[i64]) -> Result<f64, WorksheetErrorCode> {
    if items.contains(&0) {
        return Ok(0.0);
    }
    // Excel reduces the flattened values in reverse worksheet/argument order.
    // Rounded intermediates at 2^53 make this order observable.
    items
        .iter()
        .rev()
        .copied()
        .try_fold(1, lcm_int)
        .map(|n| n as f64)
}

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.

The record contains no same-input comparison between these environments. Reading different inputs on different builds does not establish either a version change or cross-build agreement.

Recorded environments and comparison details.

Alternatives

Relationships

• MOD — the divisibility primitive underneath both.
• MULTINOMIAL — the other variadic exact-integer function in this category, sharing LCM's group structural evidence record and its 2^53-scale representability problem.
• Readers most often reach for LCM for common denominators and for period alignment ("both events recur together every LCM(m, n) steps"). Both usages sit far below the documented ceiling, which is why the ceiling is rarely met in practice and rarely tested.

Named variants

No named variants are recorded yet.