GeoNum

GeoNum — Geometric Number System

GeoNum is a piecewise-approximate arithmetic system with first-class drift tracking. Every number carries an explicit uncertainty compartment (drift δ) that accumulates through operations — unlike IEEE 754 floating-point, which hides precision loss silently.

Formally citable at DOI: 10.5281/zenodo.18753425. MIT licensed. Source on GitHub.

§3.1 Encoding

Given x ∈ ℝ, x ≠ 0:
  σ  = sign(x)
  ℓ  = log₁₀|x|              [IEEE 754 log10]
  z  = min{k : B_k > ℓ}      [zone boundaries {B_k}]
  W_z = B_z − B_{z−1}         [zone width in log₁₀ space]
  ι  = (ℓ − B_{z−1}) / W_z   [normalized intensity, ∈ [0,1)]
  s  = ⌊ι × 2047⌋             [shade — TRUNCATION, not round-to-nearest]
  δ₀ = ι × 2047 − s           [initial drift ∈ [0,1)]

Zone rule: values with ℓ = B_z exactly → zone z+1 (upper boundary excluded).
Rounding: floor (truncation). Systematic underestimate of up to 1/2047 shade.
      

§3.2 Addition (same sign, σ_a = σ_b)

ℓ_a = B_{z_a−1} + ι_a · W_{z_a}     [from intensity, not shade]
ℓ_b = B_{z_b−1} + ι_b · W_{z_b}

ℓ_sum = ℓ_max + log₁₀(1 + 10^{ℓ_min − ℓ_max})   [stable log-sum-exp]
         [avoids materializing 10^ℓ — overflow-safe for |ℓ| > 308]

result = GeoNum(σ · 10^{ℓ_sum})

Drift:
  δ_result = δ_a + δ_b + |ι_a − ι_b| × 0.01

Alignment penalty: |ι_a − ι_b| × 0.01
  Heuristic — monotone in zone separation. Factor 0.01 is a design
  constant, not derived from information theory.
      

§3.3 Subtraction — Critical Limitation

sum_float = a.to_f64() + b.to_f64()    [IEEE 754 — no GeoNum protection]
result    = GeoNum(sum_float)
δ_result  = δ_a + δ_b                  [prior drift propagated; no cancellation penalty]

GeoNum does NOT protect the value of a near-cancellation subtraction.
What GeoNum DOES provide: if δ_a or δ_b is large, δ_result carries
that history. The relative drift δ / |result| diverges as result → 0,
correctly flagging unreliability. This is weaker than protecting the
subtraction itself.
      

§3.4 Multiply / Divide

ℓ_product  = ℓ_a + ℓ_b    [exact in log space — IEEE 754 double precision]
ℓ_quotient = ℓ_a − ℓ_b

δ_result = δ₀_result + 0.1 × (|δ_a| + |δ_b|)

Justification: log-space multiplication is exact to IEEE 754 double
precision — prior drift does not compound through the arithmetic itself.
The 0.1 factor is conservative headroom acknowledging that re-encoding
introduces a new δ₀. Not derived from information theory.
      

Zone Configurations

The zone boundary set {B_k} is domain-configurable. The core GeoNum arithmetic is the same in all cases — only the scale resolution changes.

Drift Interpretation

Drift δ (shade units):
  δ < 0.5      — Precise. Quantization error within design tolerance.
  0.5 ≤ δ < 1  — Caution. Error accumulating; verify with higher precision.
  δ ≥ 1        — Unreliable. Result should not be trusted without verification.

Relative uncertainty (approximate):
  u_rel ≈ (δ / 2047) × ln(10) × 100 %
      

§3.5 GPU Tessellation — 16-Limb Pairwise Tree

The GPU Reduction tab runs a WebGPU compute shader implementing GeoNum pairwise binary tree reduction. Each node stores the value as 16 non-overlapping f32 words (384 mantissa bits) using Knuth two-sum error-free transforms (EFT).

Slot layout (80 bytes):
  limbs[0..15] : f32   value = Σ limbs[i]  (non-overlapping)
  sign         : f32   ±1.0
  drift        : f32   accumulated uncertainty
  active       : f32   1.0 = live node, 0.0 = consumed

Pairwise absorb (twosum chain):
  fn absorb(a[16], b: f32):
    e = b
    for i in 0..16:
      (a[i], e) = twosum(a[i], e)   // exact — no bits lost
      if e == 0: break

Tree depth: O(log₂ N) passes
Error accumulation: O(log₂ N) instead of O(N) sequential

Precision: 16 × 24 mantissa bits = 384 bits >> MPFR-256 (256 bits)
      

Validation

Four canonical benchmarks demonstrate GeoNum's three distinct wins over IEEE 754:

GPU 16-limb tree (384 bits): harmonic sum of 16,384 terms agrees with Kahan reference to full displayed precision, with drift tracking confirming result reliability.

License & Citation

WASM API Reference

// Encode a float to GeoNum — returns [value, drift, rel_unc_%]
gn_encode(value: f64, zone: string) → [f64; 3]

// Arithmetic (pass value+drift pairs)
gn_add(a, a_drift, b, b_drift, zone) → [f64; 3]
gn_mul(a, a_drift, b, b_drift, zone) → [f64; 3]
gn_div(a, a_drift, b, b_drift, zone) → [f64; 3]

// Array operations
gn_sum_array(values: Float64Array, zone)     → [result, max_drift, rel_unc_%]
gn_product_array(values: Float64Array, zone) → [result, drift, rel_unc_%]

// Benchmarks
bench_hawking(zone)               → [ieee, gn, drift, ieee_err%, gn_err%, mpfr]
bench_alternating(n, zone)        → [ieee, gn, max_drift, ieee_err%, gn_err%, mpfr]
bench_muller(steps, zone)         → [ieee_final, gn_final, drift, true_answer=6]
bench_cancellation(n, zone)       → [ieee_diff, gn_diff, combined_drift, rel_drift]

// Physics formulas
physics_formula(name, params: Float64Array, zone) → [ieee, gn, drift, rel_unc_%]
physics_constant(name)                            → [value, abs_unc, rel_unc]
      

Precision Validation

GeoNum is validated against IEEE 754, double-double arithmetic, and MPFR-256 reference values. The table below shows the precision hierarchy, followed by benchmark results and planned extensions.

§V.1 — Precision Tier Comparison

GeoNum GPU precision comes from 16×f32 limbs per slot via Knuth two-sum EFT. Each f32 contributes 24 mantissa bits; non-overlapping limb representation gives 384 effective bits. MPFR-256 reference constants are embedded in the Rust benchmarks (DOI: 10.5281/zenodo.18753425).

§V.2 — vs Double-Double Arithmetic

Double-double (DD) arithmetic stores a value as two IEEE 754 doubles (hi, lo) with |lo| ≤ ½ ulp(hi), giving ~106 mantissa bits. It is silent — no drift readout.

§V.3 — MPFR-256 Reference Benchmarks (Validated)

§V.4 — Planned Validation Extensions

The following benchmarks are not yet implemented but are identified gaps for v2: