PRODUCT

What it does

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

PRODUCT(number1, [number2], ...) multiplies its admitted arguments and returns the product.

PRODUCT(a₁, …, a_k) = a₁ · a₂ · … · a_k

Arguments

Arguments that are numbers, logical values, or text representations of numbers are counted; arguments that are error values or text that cannot be translated into numbers cause errors.

If an argument is an array or reference, only numbers in the array or reference are counted. Empty cells, logical values, text, or error values in the array or reference are ignored.

So the same value multiplies or vanishes depending on how it arrived:

Try it

Quirks

Result and edge cases

Returns Number.

• No admitted values → 0, as above, not the mathematical empty product 1.
• A single admitted zero → 0, and it wins over everything, including values that would otherwise overflow.
• Arrays. PRODUCT is not a lift kernel; array arguments are consumed by scanning, under the right-hand column of the table above. It never returns an array.

Errors

How to implement

Numerical notes

The error bound is benign; the range is not. For k factors the relative error of a sequential product is bounded by roughly (k−1)·u/(1−(k−1)u) — linear in k, with no cancellation term, because multiplication has no catastrophic cancellation (Higham, ASNA, ch. 3). Products are accurate. What they are not is safe: the intermediate can overflow or underflow even when the final result is perfectly representable. 1e300 · 1e300 · 1e-300 is 1e300 mathematically and +∞ or #NUM! by naive evaluation, and the same happens in the underflow direction, where the loss is silent — a subnormal intermediate quietly discards bits and the final value comes back wrong rather than erroring.

The standard remedies, in increasing order of effort:

1. Accumulate the exponent separately: multiply mantissas, track a scale factor, and reassemble once at the end (frexp/ldexp style). This makes intermediate range failures impossible while keeping the same rounding sequence as the naive fold on the mantissa.
2. Sort or pair the factors so that large and small alternate — cheap, effective, and it changes the result bits, which for a compatibility-targeting implementation is a reason not to.
3. Work in logarithms only if the data is strictly positive and accuracy is not critical; the round trip through ln and exp costs far more accuracy than the fold ever did.

A natural-best implementation should take route 1. An implementation targeting Excel compatibility should take none of them until Excel's own intermediate behaviour is pinned, because each of them changes which inputs produce an error.

Rust code

aggregate(PRODUCT, "PRODUCT", NUMBERS, product)

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

• SUMPRODUCT — despite the name, not a relative: it multiplies across arrays elementwise and then sums, and it applies its own coercion rules.
• FACT, FACTDOUBLE, MULTINOMIAL — closed forms for products that PRODUCT would compute term by term, and better conditioned for it.
• POWER — PRODUCT(x,x,x) and POWER(x,3) are the same mathematics by different algorithms; see POWER on the integer-exponent path.
• AGGREGATE — the route to a product-like reduction that skips errors by declaration rather than by an undocumented scan rule. AGGREGATE has no product option, which is itself worth knowing before you plan around it.
• EXP(SUM(LN(range))) — the classical workaround for overflow, valid only for strictly positive data, and less accurate than a scaled product.

Named variants

No named variants are recorded yet.