Multiplication (*)

What it does

number1 * number2

A * B converts each operand to a number and returns the IEEE-754 binary64 product, rounded once to nearest with ties to even.

Three properties that matter in practice:

1. One rounding, not two. The exact product of two doubles generally needs about twice the significand; the operation rounds it once. That single rounding is what makes a*b reproducible across conforming platforms, and what makes (a*b)*c ≠ a*(b*c) in general — multiplication is commutative but not associative in binary64.
2. Underflow is gradual, then total. A product whose magnitude falls below the smallest normal double becomes subnormal and loses significand bits; below the smallest subnormal it becomes zero. The zero is signed, and the sign is the XOR of the operand signs.
3. The coercion is doing most of the work in real workbooks. =(A1>5)*(B1<3) multiplies two logicals — the classic array-formula spelling of AND — and depends entirely on the shared to-logical-to-number rule (TRUE→1, FALSE→0) of coercion and lifting, not on anything specific to *.

Arguments

Arity is exactly 2; no optional arguments, no defaults. Multiplication is commutative on finite numbers, so operand order does not change the value — but it does change the broadcast orientation when the operands are arrays of different shapes, so the positions are not interchangeable in the array case.

Try it

Quirks

Result and edge cases

• Text and logical operands. Shared to-number rules; * adds nothing of its own.
• Zero times anything finite is zero, with the sign given by the operand signs. The Handbook has not recorded whether the sign of that zero is observable in a published Excel result.
• Empty and omitted operands. Per-family policy under chapter 02; unrecorded here.
• Overflow and underflow. The recorded real-result policy is non_finite=allow, and the entry marks that axis default-unexamined. Overflow of a product is easy to reach (1E300 * 1E300), so this is not a hypothetical lane; it is simply unrecorded.

How to implement

Notes for implementers

• The elementwise-versus-matrix distinction is the single most common user-facing confusion on this row. An implementation that "helpfully" contracts conformable arrays is wrong; * broadcasts.
• Do not fuse. A fused multiply-add (a*b+c computed with one rounding) gives a different, usually more accurate, result than Excel's two-rounding sequence. For the excel-bitexact flavour, fusion must be disabled explicitly — many compilers will introduce it at higher optimization levels without asking.
• Guard the array orientation before the kernel. Broadcast shape selection belongs in the shared lift layer so that *, +, -, / and ^ cannot drift apart.

Rust code

CatalogueEntry::operator(TIMES, "*", Notation::Infix, NUMBERS, times)

fn times(
    arguments: &[CalcValue],
    services: &mut EvalServices<'_>,
) -> Result<CalcValue, FunctionFault> {
    binary(TIMES, arguments, services, |site, a, b| Ok(flushed(site.multiply(a, b)?)))
}

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

Version differences

No comparison between specific Excel builds is recorded here yet. This does not establish that all builds behave alike.

Alternatives

Relationships

• FUNC.OP_DIVIDE — the inverse operation, and the one that adds an error lane (#DIV/0!) * does not have.
• FUNC.OP_POWER — repeated multiplication when the exponent is an exact integer; see that page for the publication subtlety.
• PRODUCT — the aggregate. As with SUM versus +, PRODUCT scans ranges under an aggregate policy and is not * folded over a list.
• SUMPRODUCT, MMULT — elementwise-then-sum and matrix product. MMULT is emphatically not *: * on two arrays broadcasts elementwise, MMULT contracts an index.
• IMPRODUCT — complex multiplication over text-encoded complex numbers.

Named variants

No named variants are recorded yet.