5.5. Float32 Soundness
Suppose a real-valued verifier proves that the winning logit leads a competitor by 0.12. That is
not yet a statement about Float32 execution. If each rounded logit may move by 0.03, the winner
may move down while the competitor moves up, leaving only
0.12-0.03-0.03=0.06.
The classification still survives, but for a numerical reason that must appear in the proof. If
the original margin had been 0.04, the same real theorem would no longer settle the Float32
question.
This chapter follows that 0.03 backward. We first say which Float32 object it describes, then see
how an operator theorem produces a budget, how network theorems compose it, and finally how a
verifier spends it.
5.5.1. Two Float32 Objects, Two Jobs
FP32 is TorchLean's rounded-real proof model:
abbrev FP32 := NF binaryRadix fexp32 rnd32
Arithmetic is performed exactly over the reals and rounded to the binary32-precision, gradual-underflow grid with nearest-even rounding. This makes error expressions readable. The model does not contain NaN, infinity, signed zero, exception flags, or binary32 overflow to infinity; its exponent policy has no upper cutoff.
IEEE32Exec instead stores a UInt32 bit pattern and executes the binary32 special cases. It is the
right reference when a claim depends on NaN, infinity, subnormals, signed zero, or exact result bits.
The two APIs begin at the
FP32 proof semantics and the
IEEE32Exec semantics.
Exact bridge theorems join the models for covered finite-path operations: basic arithmetic, FMA,
square root, order, and min/max. Their qualifications are operation-specific; for example, division
needs a nonzero denominator and a composite expression needs finite intermediate results rather
than merely finite inputs. Executable log and tanh still need a separate accuracy or refinement
contract. A subnormal result is finite; 0/0, overflow to infinity, and square root of a negative
value are not paths that the rounded-real theorem silently absorbs.
5.5.2. Run The Two Float32 Views
TorchLean includes a small forward-and-backward comparison using the same MLP parameters in host
Float arithmetic and in the executable IEEE32Exec semantics:
lake exe torchlean float32_modes
The command first names the available meanings:
Float32 mode: FP32: proof semantics (round-on-ℝ), finite-only; no NaN/Inf Float32 mode: IEEE32Exec: executable IEEE-754 binary32 kernel (bit-level; includes NaN/Inf)
It then prints the output, parameter gradients, and input gradient for both executable paths. The final comparison on the bundled example is:
max_abs_diff(Float vs IEEE32Exec) = 0.0000000762939453835542735760100185871124267578125
This number is an observation about one input and one network. It is not a uniform error theorem.
The proof task is to derive a bound \varepsilon from input ranges, parameter ranges, and the sequence of
rounded operations, then prove that every execution covered by those hypotheses differs from the
real specification by at most \varepsilon.
Try changing the example's weights by a power of two and by a nearby non-power-of-two decimal. The former often passes through binary arithmetic exactly; the latter exposes rounding earlier. The experiment gives intuition for the formal representability and ULP theorems developed in the floating-point chapters.
5.5.3. Follow The Error Through One Linear Layer
The smallest useful network calculation is already more than one rounded operation:
y_i=b_i+\sum_{j=0}^{n-1}W_{ij}x_j.
The runtime weights, bias, and input may begin near their real counterparts. Each product introduces
another rounded result, the dot product accumulates those results in a declared order, and the bias
addition rounds once more. linearErrorBudget is the explicit expression obtained by composing the
matrix-vector and final-addition bounds. approxT_linear_fp32 proves that this expression bounds
every output coordinate.
This matters more than a theorem that merely says some tolerance exists. A caller can inspect the budget, compare it with a safety margin, and see whether wider inputs or larger weights caused the loss of precision.
import NN.Proofs.RuntimeApprox.FP32.Layers open NN.Proofs.RuntimeApprox.FP32 #check linearErrorBudget #check approxT_linear_fp32
The real side uses LinearSpec ℝ inDim outDim; the rounded side uses the same tensor
specification at scalar type R, the FP32 abbreviation in this proof namespace. approxT relates
the two tensors componentwise after interpreting the rounded values as reals. Thus the theorem is
about a shaped layer, not an isolated scalar multiply.
5.5.4. Compose The Layer Bounds Into A Network
The two-layer ReLU theorem feeds the first linear budget through the rounded ReLU rule, then uses the result as the input budget for the second linear layer. The three-layer tanh theorem repeats the same pattern through two smooth activations. Both expose their final expressions rather than hiding them behind an existential tolerance.
import NN.Proofs.RuntimeApprox.FP32.MLP open NN.Proofs.RuntimeApprox.FP32 #check reluTwoLayerMlpErrorBudget #check approxT_reluTwoLayerMlp_float32 #check tanhMlp3ErrorBudget #check approxT_tanhMlp3_fp32
These are architecture-shaped theorems for Linear → ReLU → Linear and
Linear → tanh → Linear → tanh → Linear. They demonstrate composition and cover the
corresponding examples; they are not a claim that every model assembled from arbitrary operations
already has an FP32 theorem.
5.5.5. Spend The Budget In A Verification Result
Suppose real IBP proves that an output lies in a box [\mathrm{lo},\mathrm{hi}], while the rounded network theorem
gives an error epsOut at a fixed input. Inflating every output coordinate by that amount gives
[\mathrm{lo}-\varepsilon_{\mathrm{out}},\;\mathrm{hi}+\varepsilon_{\mathrm{out}}].
ibpBound_contains_reluTwoLayerMlp_float32 proves this construction pointwise for the two-layer
ReLU MLP. It combines the real IBP theorem with approxT_reluTwoLayerMlp_float32; its named budget
is ibpReluTwoLayerErrorBudget. The budget depends on the chosen real input, while
inflateBoxUniform merely applies one chosen amount uniformly across output coordinates. To obtain
one rounded enclosure valid for every input in the input box, first prove a domain-wide upper bound
on that pointwise budget.
import NN.Proofs.RuntimeApprox.FP32.CROWN open NN.Proofs.RuntimeApprox.FP32 #check ibpReluTwoLayerErrorBudget #check ibpBound_contains_reluTwoLayerMlp_float32 #check fp32_le_of_real_le_sub_margin #check fp32_ge_of_real_ge_add_margin
For a scalar threshold, fp32_le_of_real_le_sub_margin and
fp32_ge_of_real_ge_add_margin package the same arithmetic. For a classifier, apply it to both
logits: the true logit may fall by its budget and the competitor may rise by its budget. The real
margin must pay both costs, just as in the 0.12 example at the start.
5.5.6. From The Proof Model To An Executed Program
The result so far concerns the rounded-real FP32 semantics. For a network whose primitives are
covered, an IEEE32Exec claim can use the exact finite-path bridges and discharge their domain and
finiteness hypotheses. The current bridges cover basic arithmetic, FMA, square root, order, and
min/max behavior; they do not yet give an accuracy or refinement theorem connecting executable
log or tanh to the rounded-real operations. In particular, the tanh MLP theorem above remains a
result about the FP32 proof model until such a transcendental contract is supplied.
To cite either result for Lean's host Float32, CUDA, cuBLAS, or LibTorch, one more agreement
statement must connect that provider to the executable or rounded model and must account for
reduction order, contraction, and exceptional behavior.
The float32_modes difference printed earlier is valuable regression evidence for one execution;
it is not that provider agreement theorem. A complete deployment claim therefore has a visible
chain:
real property + FP32 approximation budget + finite IEEE bridge for each covered primitive + native-provider agreement = property of the selected execution path
Some applications stop earlier because their theorem is intentionally about the rounded-real model. That is a legitimate claim as long as it says so. For the construction of the two numerical representations, read Floating-Point Semantics; for the graph and checker side of the argument, return to Neural Network Verification.
5.5.7. References
-
IEEE 754-2019 standard: https://standards.ieee.org/standard/754-2019.html
-
Goldberg, "What Every Computer Scientist Should Know About Floating-Point Arithmetic", https://dl.acm.org/doi/10.1145/103162.103163
-
Flocq: https://flocq.gitlabpages.inria.fr/
-
Higham, Accuracy and Stability of Numerical Algorithms (2nd ed., SIAM, 2002), the standard numerical analysis reference for forward error and stability arguments of the kind TorchLean packages into margin-transfer lemmas.