QUOTIENT

What it does

QUOTIENT(numerator, denominator)

QUOTIENT(numerator, denominator) returns the integer part of numerator / denominator, discarding the remainder.

QUOTIENT(n, d) = trunc(n / d)

Truncation, not floor. trunc rounds toward zero, so the sign of the numerator survives: trunc(-7/3) = -2, whereas ⌊-7/3⌋ = -3. This single choice is the whole content of the function, and it is the source of the trap in the next section.

Domain: all real n, and d ≠ 0. Range: the integers representable as binary64 — which is to say, exact integers up to 2⁵³ and even integers thereafter.

Arguments

Both are ordinary numeric slots — see Coercion and lifting. Microsoft's VBA page names both as Variant, which is consistent with text and logicals converting; the same page states the single documented error condition, quoted under Errors below.

Nothing in the documentation requires either argument to be an integer, and neither is truncated before the division: the truncation happens once, to the quotient.

Try it

Quirks

Result and edge cases

Returns Number, always an integral value (or an error).

• Signs. All four sign combinations truncate toward zero: QUOTIENT(7,3) and QUOTIENT(-7,-3) are 2; QUOTIENT(-7,3) and QUOTIENT(7,-3) are -2.
• Non-integer arguments are accepted and are not pre-rounded: QUOTIENT(7.9, 2) is 3, because 7.9/2 = 3.95 truncates to 3.

How to implement

Numerical notes

QUOTIENT looks arithmetic-free and is not.

The division rounds before the truncation. n/d is computed in binary64 and rounded to nearest; only then is the fractional part discarded. When the exact quotient sits just below an integer, the rounding can carry it up to that integer, and truncation then returns a value one larger than the true integer part. This is not hypothetical: it is the standard failure mode of every trunc(a/b) integer division in floating point, and it is why languages with exact integer types do not implement div this way. The magnitude of the exact quotient does not have to be large — it only has to be within half an ulp of an integer, which happens for perfectly ordinary decimal inputs whose binary representations are inexact.

The remedy, for an implementation that wants the true integer part, is to compute the candidate q = trunc(fl(n/d)) and then correct it using an exactly computed residual: the product d·q is exact whenever q is small enough, and fma(-d, q, n) gives the residual without rounding error, so the sign of the residual says whether q overshot. Two corrections suffice. This is the same technique used to make fmod exact, and it is cheap.

Above 2⁵³ the question changes character. There, the quotient's binary64 representation has no fractional bits at all, so "the integer part" is a property of the rounded quotient rather than of the exact one, and no post-correction recovers what was lost in the operands. An implementation should decide whether it is computing trunc of the real quotient or of the floating-point quotient, and say which. The two are different functions.

Exactness where it does hold. When d is a power of two, or when n and d are both exact integers below 2⁵³, n/d is either exact or has a well-behaved error and the naive route is correct. The overwhelming majority of spreadsheet uses live in that region, which is why the hazard above is rarely seen and, when seen, is disbelieved.

Rust code

call(QUOTIENT, "QUOTIENT", 2, FRACTION, quotient)

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 — and this is the important one. In most languages div and mod are a matched pair satisfying n = d·div(n,d) + mod(n,d). In Excel they are not a pair. QUOTIENT truncates toward zero; Excel's MOD is documented to take the sign of the divisor, which is the floored convention. With n = -7, d = 3: QUOTIENT gives -2, MOD gives 2, and 3·(-2) + 2 = -4 ≠ -7. The identity fails on every input where the operands have opposite signs. Boute's TOPLAS paper is the standard taxonomy of exactly this mismatch; Excel is one of the systems it was written about. The matching partner of Excel's MOD is INT(n/d), not QUOTIENT(n,d).
• INT — INT floors, TRUNC truncates, and QUOTIENT truncates a quotient. For positive operands all three agree, which is why the difference is usually discovered in production.
• TRUNC — QUOTIENT(n,d) and TRUNC(n/d) are the same computation, with one difference that matters: n/d written as an expression yields #DIV/0! on a zero divisor from the operator, whereas QUOTIENT yields it from the function. There is no accuracy difference; both form the quotient in binary64 first.

Named variants

No named variants are recorded yet.