An 83-Format Numeric Catalog with Bit-Exact Conformance Vectors: A Vendor-Neutral Reference for FP8, BF16, MXFP4, and Microscaling Formats
Pith reviewed 2026-06-27 14:32 UTC · model grok-4.3
The pith
This paper supplies an 83-format catalog and six bit-exact conformance packs as a vendor-neutral reference for FP8, BF16, MXFP4 and microscaling formats.
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
Core claim
The paper presents an 83-format numeric catalog spanning 13 families together with six bit-exact conformance packs for GF16, MXFP4 element, BF16, FP8 E4M3, FP8 E5M2, and E8M0 block scale, each delivered as a self-contained JSON document that includes a SHA-256 fingerprint, a shared row schema, and an anchor vector encoding the value 3.0 as a cross-pack sanity check, accompanied by an IEEE P3109 v3.2.0 cross-walk that maps every pack to its standards-track configured format.
What carries the argument
The bit-exact conformance pack, a JSON document that stores vectors encoding precise bit-level behavior for each format and is anchored by a shared sanity-check vector for the value 3.0.
If this is right
- Engineers obtain a single public reference that flags silent divergences when porting models across accelerators.
- Each pack maps directly to an IEEE P3109 v3.2.0 configured format via the supplied cross-walk.
- Divergences between the packs and ml_dtypes 0.5.4 are explicitly recorded as spec-permitted gaps.
- The catalog and packs can be used as a baseline without asserting superiority over any vendor implementation.
Where Pith is reading between the lines
- The JSON packs could be imported into automated test suites to enforce consistent numeric behavior across libraries.
- The anchor vector for 3.0 offers a simple, format-independent way to verify that a new pack was generated correctly.
- Extending the same pack structure to additional research formats would keep the registry uniform.
Load-bearing premise
The conformance packs correctly encode the bit-exact behavior of each format so that any difference with ml_dtypes represents a permitted interpretation gap rather than an error in pack construction.
What would settle it
A direct comparison in which one of the supplied packs produces a different result from the IEEE P3109 specification or from hardware for the same input bit pattern.
read the original abstract
Numeric format proliferation in machine learning hardware -- FP8 (E4M3 and E5M2), BF16, MXFP4, microscaling block formats, and dozens of research variants -- has outpaced the availability of vendor-neutral, bit-exact reference material. Engineers porting models across accelerators encounter silent divergences that are difficult to diagnose without a shared ruler. This paper describes a catalog of 83 numeric formats spanning 13 families, a suite of six bit-exact conformance packs covering GF16, MXFP4 element, BF16, FP8 E4M3, FP8 E5M2, and E8M0 block scale, and an IEEE P3109 v3.2.0 cross-walk that maps each pack to its corresponding standards-track configured format. Each pack is a self-contained JSON document with a SHA-256 fingerprint, a shared row schema, and an anchor vector that encodes 3.0 -- the identity phi^2 + 1/phi^2 = 3 -- as a cross-pack sanity check. Packs are cross-validated against ml_dtypes 0.5.4 (Google/JAX); any divergence is documented explicitly and interpreted as a spec-permitted interpretation gap rather than hidden. The work is framed as registry filling: it does not propose new formats, make model-accuracy claims, or assert superiority over any vendor's implementation. All artifacts are publicly available at https://github.com/gHashTag/t27 under an open license.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The manuscript presents a catalog of 83 numeric formats spanning 13 families, along with six self-contained JSON conformance packs (for GF16, MXFP4 element, BF16, FP8 E4M3, FP8 E5M2, and E8M0 block scale) that include SHA-256 fingerprints, a shared row schema, and a phi-based anchor vector encoding the identity phi^2 + 1/phi^2 = 3 as a cross-pack sanity check. It also supplies an IEEE P3109 v3.2.0 cross-walk mapping each pack to the corresponding standards-track format. The packs are cross-validated against ml_dtypes 0.5.4, with any divergences explicitly documented and labeled as spec-permitted interpretation gaps rather than errors. The work is positioned strictly as registry filling without new format proposals or accuracy claims.
Significance. If the bit-exact claims hold, the contribution supplies a much-needed vendor-neutral reference for the rapid proliferation of low-precision formats in ML hardware, enabling consistent diagnosis of silent divergences across accelerators. The open release of the JSON packs and catalog under an open license at the cited GitHub repository, combined with explicit cross-validation and the anchor-vector sanity check, makes the artifacts directly testable by third parties and strengthens its value as a shared reference.
minor comments (2)
- The abstract and introduction would benefit from a brief table or enumerated list (e.g., in §2) explicitly naming the six conformance packs and their corresponding JSON filenames or SHA-256 values to improve immediate navigability for readers.
- Section describing the anchor vector should clarify whether the phi-based encoding is applied uniformly to all six packs or only to a subset, and whether the 3.0 identity is verified in the released JSON files themselves.
Simulated Author's Rebuttal
We thank the referee for their positive assessment and recommendation to accept the manuscript. The work is positioned as a registry and reference artifact rather than a research contribution proposing new formats, and we are gratified that this framing and the provided conformance packs are viewed as valuable for the community.
Circularity Check
No significant circularity
full rationale
The paper is a purely descriptive registry and reference work: it compiles an 83-format catalog, releases six self-contained JSON conformance packs with SHA-256 fingerprints and an external phi-based anchor, and supplies an IEEE P3109 cross-walk. No equations, fitted parameters, predictions, or derivations appear. Divergences versus ml_dtypes are explicitly documented as permitted gaps rather than hidden. All artifacts are open and externally testable; the central claim does not reduce to any self-citation chain or input-by-construction step.
Axiom & Free-Parameter Ledger
axioms (1)
- domain assumption Existing numeric format specifications from vendors and IEEE P3109 are accurate and complete for the purposes of conformance packing.
Forward citations
Cited by 1 Pith paper
-
GoldenFloat: A Phi-Derived Static-Split Floating-Point Family from GF4 to GF1024 with a Lucas-Exact Integer Identity
GoldenFloat introduces a phi-derived rule for setting exponent and fraction widths across floating-point formats from 4 to 1024 bits, backed by open RTL generator, Lucas-exact accumulator, and FPGA implementation.
Reference graph
Works this paper leans on
-
[1]
GoldenFloat: A phi-anchored numeric format family and the identityφ2+1/φ2 = 3,
D. Vasilev, “GoldenFloat: A phi-anchored numeric format family and the identityφ2+1/φ2 = 3,” arXiv:2606.05017, 2026.https://arxiv.org/abs/2606.05017
Pith/arXiv arXiv 2026
-
[2]
Takum arithmetic: A new paradigm for low-precision numerics,
C. Hunhold, “Takum arithmetic: A new paradigm for low-precision numerics,” arXiv:2412.20273, 2024.https://arxiv.org/abs/2412.20273
arXiv 2024
-
[3]
ProofWright: Towards verified floating-point arithmetic,
C. Park, J.-H. Lim, S. Nagarakatte, “ProofWright: Towards verified floating-point arithmetic,” arXiv:2511.12294v2, 2025.https://arxiv.org/abs/2511.12294
arXiv 2025
-
[4]
P3109 FLoPS: A Lean 4 formalization of IEEE P3109 floating-point semantics,
C. Chang, C. Park, J.-H. Lim, S. Nagarakatte, “P3109 FLoPS: A Lean 4 formalization of IEEE P3109 floating-point semantics,” arXiv:2602.15965, 2026. https://arxiv.org/abs/2602. 15965
Pith/arXiv arXiv 2026
-
[5]
Microscaling data formats for deep learning,
B. Rouhani et al., “Microscaling data formats for deep learning,” arXiv:2310.10537, 2023. https://arxiv.org/abs/2310.10537
arXiv 2023
-
[6]
KernelBench: Can LLMs write efficient GPU kernels?,
A. Ouyang et al., “KernelBench: Can LLMs write efficient GPU kernels?,” arXiv:2502.10517, 2025.https://arxiv.org/abs/2502.10517
Pith/arXiv arXiv 2025
-
[7]
Introducing NVFP4 for efficient and accurate low-precision infer- ence,
NVIDIA, “Introducing NVFP4 for efficient and accurate low-precision infer- ence,” NVIDIA Technical Blog, 2025. https://developer.nvidia.com/blog/ introducing-nvfp4-for-efficient-and-accurate-low-precision-inference/
2025
-
[8]
M. Wang et al., “ M 2XFP: A unified mixed-precision microscaling floating-point representation for next-generation AI accelerators,” arXiv:2601.19213, 2026 (to appear, ASPLOS ’26). https: //arxiv.org/abs/2601.19213
arXiv 2026
-
[9]
Low-precision floating-point formats: The wild west of computer arith- metic,
N. J. Higham, “Low-precision floating-point formats: The wild west of computer arith- metic,” SIAM News, 2017. https://www.siam.org/publications/siam-news/articles/ low-precision-floating-point-formats-the-wild-west-of-computer-arithmetic/
2017
-
[10]
Pychop: Emulating low-precision arithmetic in Python for ML and scientific computing,
E. Carson, X. Chen, “Pychop: Emulating low-precision arithmetic in Python for ML and scientific computing,” arXiv:2504.07835, 2025.https://arxiv.org/abs/2504.07835
arXiv 2025
-
[11]
Floating-point conformance testing in industrial practice,
C. M. Wintersteiger, “Floating-point conformance testing in industrial practice,” Proc. IEEE ARITH 2025.https://arith2025.org/proceedings/215900a157.pdf
2025
-
[12]
libtakum: A reference C library for takum arithmetic,
C. Hunhold, “libtakum: A reference C library for takum arithmetic,” GitHub, 2024–2025. https://github.com/takum-arithmetic/libtakum
2024
-
[13]
Takum arithmetic in sparse iterative solvers: A precision-vs-storage study,
C. Hunhold, T. Quinlan, “Takum arithmetic in sparse iterative solvers: A precision-vs-storage study,” arXiv:2412.20268, 2024.https://arxiv.org/abs/2412.20268
arXiv 2024
-
[14]
8-bit numerical formats for deep neural networks,
B. Noune et al., “8-bit numerical formats for deep neural networks,” arXiv:2206.02915, 2022. https://arxiv.org/abs/2206.02915 16
arXiv 2022
-
[15]
https://standards.ieee.org/ieee/754/6210/
IEEE Std 754-2019,IEEE Standard for Floating-Point Arithmetic, Institute of Electrical and Electronics Engineers, New York, NY, 2019. https://standards.ieee.org/ieee/754/6210/
2019
-
[16]
https://www.opencompute.org/documents/ ocp-microscaling-formats-mx-v1-0-spec-final-pdf
Open Compute Project,OCP Microscaling Formats (MX) Specification v1.0, Open Compute Project Foundation, 2023. https://www.opencompute.org/documents/ ocp-microscaling-formats-mx-v1-0-spec-final-pdf
2023
-
[17]
https://github.com/jax-ml/ml_dtypes
Google/JAX, ml dtypes version 0.5.4: Low-precision float types for NumPy and JAX, 2024. https://github.com/jax-ml/ml_dtypes
2024
-
[18]
https://github.com/P3109/ Public
IEEE P3109 Working Group,IEEE SA P3109 Interim Report v3.2.0: Standard for Floating- Point Arithmetic for AI, IEEE Standards Association, 2026. https://github.com/P3109/ Public
2026
-
[19]
A. Fitzgibbon, C. M. Wintersteiger, and J. Sarnoff,Novel Aspects of IEEE SA P3109 Arithmetic Formats for Machine Learning. arXiv:2606.04028, 2026. https://arxiv.org/abs/2606.04028
Pith/arXiv arXiv 2026
- [20]
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.