pith. sign in

arxiv: 2606.09686 · v2 · pith:ORND57HGnew · submitted 2026-06-08 · 💻 cs.AR · cs.AI· cs.MS· cs.NA· cs.PF· math.NA

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

classification 💻 cs.AR cs.AIcs.MScs.NAcs.PFmath.NA
keywords numeric formatsFP8BF16MXFP4microscalingconformance vectorsIEEE P3109bit-exact reference
0
0 comments X

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.

The paper assembles a catalog of 83 numeric formats across 13 families and releases six self-contained JSON conformance packs that encode exact bit behavior for GF16, MXFP4 element, BF16, FP8 E4M3, FP8 E5M2, and E8M0 block scale. Each pack carries a SHA-256 fingerprint, a shared row schema, and an anchor vector that checks the identity phi squared plus one over phi squared equals three. The packs are cross-checked against ml_dtypes 0.5.4 with every divergence recorded as a documented interpretation gap, and an IEEE P3109 v3.2.0 cross-walk maps each pack to the corresponding standards-track definition. The work is presented strictly as registry filling that supplies a shared ruler without introducing new formats or accuracy claims.

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

These are editorial extensions of the paper, not claims the author makes directly.

  • 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.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

0 major / 2 minor

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)
  1. 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.
  2. 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

0 responses · 0 unresolved

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

0 steps flagged

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

0 free parameters · 1 axioms · 0 invented entities

This is a reference catalog with no new free parameters, axioms beyond standard domain knowledge of numeric formats, or invented entities.

axioms (1)
  • domain assumption Existing numeric format specifications from vendors and IEEE P3109 are accurate and complete for the purposes of conformance packing.
    The catalog and packs rely on these specifications as the basis for bit-exact representations.

pith-pipeline@v0.9.1-grok · 5833 in / 1380 out tokens · 28378 ms · 2026-06-27T14:32:22.247142+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. GoldenFloat: A Phi-Derived Static-Split Floating-Point Family from GF4 to GF1024 with a Lucas-Exact Integer Identity

    cs.AR 2026-06 unverdicted novelty 4.0

    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

20 extracted references · 4 linked inside Pith · cited by 1 Pith paper

  1. [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

  2. [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

  3. [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

  4. [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

  5. [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

  6. [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

  7. [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/

  8. [8]

    M 2XFP: A unified mixed-precision microscaling floating-point representation for next-generation AI accelerators,

    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

  9. [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/

  10. [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

  11. [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

  12. [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

  13. [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

  14. [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

  15. [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/

  16. [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

  17. [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

  18. [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

  19. [19]

    Fitzgibbon, C

    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

  20. [20]

    Fasoli, M

    A. Fasoli, M. Kar, C.-C. Liu, S. Venkataramani, V. Srinivasan, L. Chang, and N. Wang,Is Finer Better? The Limits of Microscaling Formats in Large Language Models. arXiv:2601.19026, 2026.https://arxiv.org/abs/2601.19026 17