Base-N & Number System Converter

Inspectable records

Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Area

Mathematics — arithmetic through advanced (algebra, matrices, calculus, sequences/series, number theory, combinatorics, graphing, complex numbers, geometry, logic, sets)

Tranche

tranche-6

Evidence ID

t6-056

Ledger rows

1

No ledger note is attached.

Review findings

The positional conversion claim is broadly standard, but the Roman and especially Egyptian-fraction claims are underspecified. The empty honest_label should be replaced with an explicit scope such as supported base syntax, exactness/precision policy, canonical Roman range, and the chosen Egyptian-fraction algorithm.

Formula and scope findings

• Positional expansion/collapse is appropriate for bases 2-36, but the specification does not define the digit alphabet and case rules, validation of digits, signed numbers, or handling of finite versus repeating fractional expansions.
• A Roman numeral symbol lookup table alone is insufficient: the formatter/parser must define standard subtractive pairs, canonical output rules, valid range, and treatment of zero, negatives, and values above the supported range.
• Egyptian-fraction conversion is claimed but no Egyptian-fraction algorithm is specified. The result is non-unique unless a convention such as greedy unit-fraction decomposition is required.
• The input description only mentions number and source/target base, but Roman-numeral and Egyptian-fraction modes require an explicit mode and representation contract.

Unit assumptions

• All values are dimensionless exact integers or rational numbers; no physical-unit conversion is involved.
• A positional numeral in base b represents the sum of digit times b raised to each place value, with b an integer from 2 through 36.
• For these vectors, base digits use 0-9 followed by A-Z, case-insensitively, and fractional parts are interpreted as exact finite base expansions.
• Roman numerals use canonical modern notation with subtractive pairs IV, IX, XL, XC, CD, and CM, and the supported positive range is assumed to be 1 through 3999.
• Egyptian fractions are assumed to mean positive rational numbers represented as a sum of distinct positive unit fractions, using the greedy algorithm.

Boundary hardening

Recorded hazards

• Reject source or target bases outside the inclusive range 2-36, and reject digits whose numeric value is at least the base.
• Define behavior for lowercase versus uppercase digits and for signs, whitespace, malformed radix points, and multiple radix points.
• A finite fraction in one base may require a repeating expansion in another base; the implementation needs a repeating notation, precision limit, or explicit exact-fraction output policy.
• Protect against integer overflow or loss of exactness in JavaScript Number arithmetic; BigInt or rational arithmetic may be required for exact conversions.
• Roman numeral parsing must reject noncanonical or invalid subtractive forms and define behavior for zero, negative values, and values greater than 3999.
• Egyptian fractions can have multiple valid decompositions; without a stated algorithm and canonicality rule, outputs cannot be uniquely verified.
• Egyptian-fraction input must reject a zero denominator and define behavior for zero, negative, improper, or non-reduced fractions.
• Repeated division by the radix must terminate for integer conversion, but fractional conversion can fail to terminate without a stopping policy.

Errata and corrections

No applied erratum is attached to this unique-name record.

Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

{
  "inputs": {
    "mode": "positional",
    "number": "0",
    "source_base": 10,
    "target_base": 2
  },
  "expected_outputs": {
    "converted": "0",
    "value_in_source_base": 0
  },
  "working": "0 in base 10 has no nonzero place values. The same value in every positional base is 0, so 0_10 = 0_2. This is the zero-value boundary case."
}

Related workflows

No source-defined multi-instrument workflow membership is recorded.

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json · VERIFIED_CLEAN
• evidence-tranche6/tranche6-results.json