BASE

What it does

BASE(number, radix, [min_length])

BASE(number, radix, [min_length]) writes a non-negative integer in a positional numeral system of the given radix, and returns the result as text.

For an integer n >= 0 and a radix b >= 2, the positional representation is the unique finite sequence of digits d_k d_(k-1) ... d_1 d_0 with

n = sum over i of d_i * b^i,     0 <= d_i < b,     d_k != 0 (for n > 0)

Uniqueness is the theorem that makes the function well defined: for every b >= 2 and every n >= 0 there is exactly one such sequence. It fails for b = 1 (no positional system exists) and for b = 0 (nothing exists), which is why those radices must be rejected rather than given some convention.

The digits are extracted by the standard recurrence

d_i = floor(n / b^i) mod b,

equivalently by repeated division: divide by b, record the remainder, repeat on the quotient until it is zero, and reverse. The number of digits is floor(log_b n) + 1 for n >= 1, and 1 for n = 0.

min_length pads on the left with zeros. Microsoft's Learn reference documents the parameter as "the minimum length of the returned string" and states that if it is omitted, leading zeros are not added. Padding never truncates: a representation longer than min_length is returned in full.

Arguments

The misunderstood position is the return kind: BASE returns Text, not a number. BASE(255, 16) is the string "FF", and BASE(9, 10) is the string "9", which will not compare equal to the number 9 under =. Feeding a BASE result into arithmetic re-coerces it, and for radices other than 10 that coercion means something entirely different from the digits you wrote.

Try it

Quirks

Result and edge cases

Returns Text.

• Zero is representable and its representation is the single digit 0 in every radix.
• Negative number. There is no sign convention in the mathematics above, and the reference engine's battery rejects negative inputs. This is the single biggest behavioural difference from the fixed-radix conversion family — see Relationships.
• Radix 0 and radix 1 are rejected: no positional system exists for either.
• Radix above 36 exceeds the digit alphabet.
• Very large number. The hard limit is 2^53, and the reason is the argument type rather than the algorithm — see the numerical notes.
• min_length larger than the representation pads; smaller has no effect; zero or omitted means no padding.
• Arrays. All argument positions broadcast. The evidence record attached to this page concerns exactly that: BASE is a named subject of an array-lift tranche, with its own witness row about a radix argument supplied as an array producing a text-valued array result.

Errors

The condition column is deliberately imprecise about the exact bounds, because the exact bounds are undocumented in every source the Handbook retrieved. Sharpening it is what the probe list is for.

How to implement

Numerical notes

BASE has no rounding error — every digit it produces is exact — but it sits on top of a floating-point argument, and that is where all of its numerical content lives.

The 2^53 boundary. number arrives as a binary64 double. Doubles represent every integer up to 2^53 exactly; above that, only even integers, then only multiples of 4, and so on. So for arguments above 2^53 the value the function receives is not the integer the user wrote, and any representation it produces is the correct representation of a different number. There is no way for the function to detect this — the information is gone before the call. That is why 2^53 is the natural upper bound for a radix formatter over doubles, and why an implementation that quietly accepts larger arguments is producing digits that look authoritative and are not.

This is the same boundary that limits exact integer arithmetic everywhere in the worksheet, made unusually visible because BASE's whole output is digits.

The digit-count trap. The tempting way to size the output buffer, or to compute a digit, is floor(log(n) / log(b)) + 1. This is wrong at and near exact powers of the radix: LOG10(1000) computed in floating point can land just below 3, and the formula then reports three digits where four are needed. Every careful implementation either computes the digit count by the repeated division itself, or computes it by logarithm and then verifies against a power. Knuth's treatment of radix conversion in TAOCP volume 2 section 4.4 is the standard reference; the general lesson is that a logarithm should never be the sole source of an integer count.

Repeated division versus repeated multiplication. Extracting digits least-significant-first by n mod b then n = floor(n/b) is exact in integer arithmetic and, because every intermediate stays below the starting value, exact in doubles too as long as the start is below 2^53. Extracting most-significant-first by dividing by b^k requires forming b^k, which is exactly representable only for small k in most radices, and is therefore the worse algorithm on a floating-point substrate.

Padding is not formatting. min_length pads with the digit zero, which is a semantically meaningful character in a positional system, not a cosmetic space. Padding a base-16 value to eight places produces a string that reads correctly as a base-16 numeral; the TEXT function's padding would not.

Rust code

43 base "BASE" (2, 3) [V "number", V "radix", V "min_length"] |s, a, sv| {
    let n = num(s, a, 0)?;
    let radix = num(s, a, 1)?;
    let min_length = if given(a, 2) { Some(num(s, a, 2)?) } else { None };
    out_text(k::base_fn::base_kernel(n, radix, min_length))
}

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

• DECIMAL — the inverse. DECIMAL(BASE(n, b), b) should recover n for every admissible n and b, and that round trip is the best oracle-free test for the pair. DECIMAL(text, radix) reads what BASE writes.
• DEC2BIN, DEC2HEX, DEC2OCT — the fixed-radix conversions, and they are not special cases of BASE. Three differences matter:
  1. They accept negative numbers and encode them in two's complement over a fixed width; BASE has no sign convention at all.
  2. They have narrow ranges (a small number of places) where BASE runs to the exactly-representable-integer limit.
  3. They take a places argument that behaves like min_length but is bounded. A formula that swaps DEC2HEX for BASE(x, 16) changes behaviour on every negative input and on every large one.
• BIN2DEC, HEX2DEC, OCT2DEC — the fixed-radix readers, DECIMAL's specialised cousins, with the same two's-complement asymmetry.
• BITAND and the bit-operation family — the other place the 2^48-and-beyond integer limits of Excel's numeric model surface.
• ROMAN / ARABIC — the non-positional pair, and the useful contrast: BASE and DECIMAL are a clean bijection on their domain because positional representation is unique, whereas ROMAN and ARABIC are not, because Roman notation is not.
• TEXT — the general formatter, which cannot do radix conversion.
• Confused with: DEC2HEX, constantly, and with the idea that BASE returns a number.

Named variants

No named variants are recorded yet.