bitrep — any order, any hardware, same bits
Floating-point addition isn't associative, so the order of a sum changes the answer — and parallelism, sharding and batch size all change the order. More precision makes the wrong bits smaller. It can't make the bytes equal. If you sign, hash, replicate or compare results, fp64 fixes your decisions — it can't fix your hashes.
bitrep is an open-source library — usable from Rust, JavaScript, and Python (crates.io, npm, PyPI) — whose accumulator state is exact and order-invariant by construction: sums computed in any order, on any number of machines, on any CPU architecture, produce byte-identical results — and 289-byte serialized states that merge exactly. The JavaScript package is the crate compiled to WebAssembly and the Python package is a native extension, so a receipt hashed in Python matches one hashed in JavaScript byte-for-byte.
Measured, on every commit
4 → 1
architectures (x86-64 Linux, ARM64 macOS, Windows, wasm32) — one SHA-256, asserted in CI on every commit
4 → 1
worker configurations in data-parallel SGD — naive f64 yields 4 different models; bitrep yields 1, byte-identical
±∞
what a naive f64 sum of the reference dataset returns depending on shuffle order — bitrep's hash never moves
The browser demo runs the crate's actual cross-architecture reference test on your device — not a video of it, the test itself, compiled to WebAssembly. Sum 11,007 hostile values, hash the accumulator state, and compare against the hash pinned in CI. Then shuffle the data, shard it 37 ways, merge accumulator states from your phone to your laptop — the bytes don't move.
Proved, checked, fuzzed, cross-examined
Each layer is verified by an independent method, so no single mistake can hide — and the division of labor is stated, not implied:
Lean 4 proofs (zero sorry, axiom-audited in CI) — order/merge-tree/permutation invariance of exact accumulation; the rounding kernel is round-to-nearest-ties-to-even in full; the float counter CRDT’s convergence laws; and the v0.2 toolkit merge algebra — products, keyed maps, min/max joins, saturating counters.
Kani / CBMC bounded model checking — the Rust implementation’s merges commute and associate and the codecs round-trip — for all inputs, symbolically, on every push (six harnesses). Its first catch on v0.2: adversarial decodes broke a merge law; the decoder now rejects non-canonical states.
Differential fuzzing vs a BigInt oracle — hundreds of millions of executions; catches include a real bug (fixed), a bug in its own oracle (the crate was right), and a length-prefix overflow in a v0.2 decoder — found in under a minute of fuzzing the new code.
NIST StRD certified datasets — certified means reproduced to the representational limit.
Cross-language conformance — a pure-Python implementation reproduces the Rust crate byte-for-byte from the format spec alone.
Honest costs, measured: roughly 5–10× a naive loop, 1.2–2.5× Kahan summation — and the xsum crate is ~3× faster for raw single-machine exact sums at large n. bitrep's price buys what xsum doesn't offer: the mergeable, serializable, canonically-encoded state that makes distributed aggregation, signatures and replication work.
What this unlocks
Signable percentiles — a reproducible quantile sketch (v0.4)
v0.4 adds RelSketch: a relative-error quantile sketch (DDSketch-family) whose state is byte-identical across insertion order, sharding and hardware, and hashes canonically — so a p99, a p99.9 or a VaR becomes a receipt you recompute and verify, not a number you trust from a dashboard. Merge the sketches from a hundred shards in any order and get the same signed bytes; additive/homomorphic commitments can sign a sum but not a percentile — this can. Merge laws machine-checked in Lean; shares the OpenTelemetry/Prometheus exponential-histogram bucket family, so you can emit a signed receipt alongside the histogram you already export.
Float CRDTs — counters to statistics (v0.2)
Counter CRDTs were integer-valued for fifteen years because CRDT merge must commute and associate — properties float addition lacks and bitrep restores, machine-checked in Lean. v0.2 generalizes the construction to a statistics algebra: replicated mean, variance, kurtosis, covariance and regression that converge to the same bits on every replica, exactly rounded — where the textbook parallel formula returns a different answer per merge tree (and, under cancellation, a negative variance).
Numeric aggregates for local-first apps
The CRDT ecosystem (Automerge, Yjs, ElectricSQL, Ditto) has counters and text but no exact numeric aggregation — float sums don’t converge. bitrep’s v0.2 stats types do: offline devices accumulate, sync in any order, and every device shows the same mean, variance and regression. The missing numeric primitive for offline-first dashboards and spreadsheets.
Replicated & streaming database aggregates
SUM, AVG, VAR, STDDEV, COVAR, CORR and REGR_* as mergeable states, grouped by key or window. Exact retraction means insert-then-delete returns to byte-identical state — so backfills and reprocessing stop changing the answer. Incremental view maintenance that’s exact.
Signed and auditable statistics
Every state hashes canonically, so a signed total, an SLO report, a risk number or a pooled regression becomes a receipt: recompute it from the inputs and the hash matches — or a contribution was dropped, duplicated or altered. (A Merkle tree over accumulator states gives O(log n) verifiable updates of a signed total.)
Retry-immune & federated aggregation
Sum a billion numbers on a hundred workers and merge the 289-byte states in any arrival order — retries, stragglers and rebalancing stop mattering. Across organizations, sites share ~500-byte states instead of raw data and merge to exact pooled statistics (auditability, not privacy — compose with DP where needed).
Prior art, credited: the superaccumulator is classic (Kulisch; Neal 2015; Demmel–Nguyen reproducible BLAS). bitrep's contribution is the distributed packaging — the mergeable canonical state — and the machine-checked, cross-architecture proof harness.