binary256

A binary256 value is a sign, a biased exponent and a fraction, packed as s · e · f from the most significant bit down. When the exponent field is neither all zeros nor all ones the value is (−1)s × 1.f × 2e − 262143: the leading 1 is implied, so 236 stored bits give 237 bits of precision. All zeros in the exponent means a subnormal, (−1)s × 0.f × 2-262142, which lets the format lose precision gradually rather than dropping to zero. All ones means infinity when the fraction is zero and a NaN otherwise; the fraction's top bit says whether the NaN is quiet or signaling.

Precision is 237 bits, which is 71.34 decimal digits: any decimal with 71 significant digits survives a round trip through binary256, and 73 digits are enough to write any binary256 value down so that it reads back to the same bits. Every integer up to 2²³⁷ = 2^237 (about 2.21e71) is exact; above it the spacing between representable numbers is 2, then 4, then 8, and an integer that lands between them is rounded to a neighbour. The largest finite value is about 1.61e78913, the smallest normal about 2.48e-78913, and the subnormals reach down to 2^-262378, about 2.25e-78984.

The spacing is what matters in practice. Between two consecutive powers of two the representable values are evenly spaced, 2²³⁶ of them per binade, and the spacing doubles with every binade. Relative to the value it is always between 2⁻²³⁷ and 2⁻²³⁶; absolute, it depends entirely on how big the value is.

IEEE 754 defines binary256 without naming it a basic format: clause 3.6 gives the formulas for any binaryk with k a multiple of 32 above 128, and then uses this one as its worked example, "binary256 would have p = 237 and emax = 262143". No language has a keyword for it. No commercial processor computes it. The libraries that reach it are multiprecision libraries set to 237 bits, which is close to the format and, as the cases below show, not the same thing.

The one hardware implementation is the cft-fp256 tile, an FPGA design for the AMD Alveo U50 whose 256-bit lane computes one binary256 element per beat with a 237-bit significand, or splits into two binary128, four binary64 or eight binary32. It reproduces the published vectors on silicon to the same bits as the software backend that runs this page. In software, that library runs on anything with a C compiler, on this tab, on a Raspberry Pi Pico and on an ESP32.

binary256 has a failure mode unlike the narrower formats': there is no second implementation to disagree with. At binary64 two libms differ in the last bit; at binary256 there is one library and a handful of multiprecision packages that approximate the format without being it. MPFR at 237 bits has a different exponent range, no subnormals unless you emulate them, no signaling NaNs and no payloads, so an MPFR result and a binary256 result are the same number only when nothing near an edge happened. The other failure is the honest one: for most computations, seventy-one digits are sixty more than the method deserves, and a fifteenth-order integrator at binary256 produces the same digits it produced at binary128. The cases below show the edges, which is where the format is a format and not a precision setting.

Every arithmetic operation computes the exact result and then rounds it once, under one of five attributes: to nearest with ties to even (the default everywhere), toward zero, toward −∞, toward +∞, and to nearest with ties away from zero. The directed attributes are how interval arithmetic gets rigorous bounds; ties-to-away is what some decimal conventions expect. Alongside the result, five flags record what happened: inexact when rounding changed the value, underflow when a tiny result was also inexact, overflow when the exact result was too large, divideByZero for a finite divided by zero, and invalid for an operation with no meaningful answer, such as 0/0 or ∞ − ∞, which delivers a quiet NaN.

Ranked by what the work is. At this width the question is rarely "which library is fastest" and usually "does this library mean the same thing as the format".

At binary32 and binary64, "same bits everywhere" is a claim about agreement between implementations that already exist. At binary256 there are no others, so the claim has to be made differently: publish the definition, make it checkable by anyone, and hold the one implementation to it with the one independent arbiter that reaches the format. cft-fp256's definition is an exact, dependency-free Python model of every operation, from which 1,068,915 conformance cases are generated deterministically and published; the C library, the WebAssembly build running in this tab, the microcontroller build and the FPGA tile are all scored against those cases and never against each other. GNU MPFR, at 237 bits with the format's range emulated, arbitrates 739,234 transcendental cases and 999,000 division and square-root cases across the four formats with zero value and zero flag mismatches.

The replay below runs this format's sample of those cases through the reference implementation itself, here. The one program in nine languages prints 0x0eea048c14040a4e over this format's vectors on every platform in the project's compatibility record, and the card reproduced every published case on silicon through one tile and through four.

What the width is for is measured rather than argued, in the project's five workloads, each written for a property the contract has and a conventional library does not. A deep-zoom Mandelbrot reference orbit at a magnification where one pixel is 3.1e-61 wide: binary256 holds the centre to zero pixels of error, and a binary64 reference is 9.4e30 pixels off, wrong from iteration 1, with every flag clear (ZOOM.md). Exact integer arithmetic below 2²³⁷, with the inexact flag as a certificate: Collatz trajectories and Lucas-Lehmer on 59-bit limbs through 2¹⁹⁹³⁷ − 1 (MERSENNE.md). Rigorous enclosures, where 14 of 15 ill-conditioned binary64 enclosures straddle zero and 0 of 15 at binary256 (ENCLOSE.md). A symplectic orbit whose angular-momentum drift is 9.0e-69 against binary64's 1.4e-13 on the same steps, 2¹⁸⁴ apart, while the energy drift, which is the method's, is identical at every format (ORBITS.md). All five run in a browser on the demos page, each checksum-matched to its C tool.

The measured case against this format comes before the case for it. cft-rebound's horizon study ran REBOUND's IAS15 integrator at binary64, binary128 and binary256 on the same problems and steps, and at every step size a user would choose, binary256 produced the same digits as binary128: a fifteenth-order method's truncation error, which scales as dt¹⁵, sits far above the binary128 floor until the steps are absurdly small. The one regime the sweep found where the width mattered was the outer solar system at ten-to-twenty-day steps, worth one to six orders. Everywhere else, the cost was real, ten to twenty corrector passes a step against four to nine, and the benefit was zero. If the method's error is above the binary128 floor, binary128 is the answer and it is one click left.

binary256 earns its place where the arithmetic itself is the object: a chaotic map iterated thousands of times from a point that has to be exactly the point, an integer that has to stay an integer to 2²³⁷, an enclosure that has to be narrow enough to exclude zero, a libm at a narrower format that has to be checked to more than twice its own precision. Those are the workloads above, and they are the reason a tile exists for this rung and not, say, for binary512.