Cross-backend parity
omnibias guarantees that a given (activation, order) pair is float64-ULP-
equal across PyTorch, JAX, and Keras 3. This page explains why, and how to
check it yourself.
Why it holds
There is exactly one definition of the polynomial coefficients, in
pure-Python omnibias-core. Each backend imports it and applies it with its own
tensor type. There is no per-backend reimplementation that could drift.
Verify it yourself
import numpy as np
import torch, jax.numpy as jnp
from omnibias.torch import get_activation as torch_act
from omnibias.jax import get_activation as jax_act
z = np.linspace(-3, 3, 101).astype(np.float64)
for n in range(6):
t = torch_act("tanh").fastpath(torch.tensor(z, dtype=torch.float64), n).numpy()
j = np.asarray(jax_act("tanh").fastpath(jnp.asarray(z), n))
assert np.max(np.abs(t - j)) <= 1e-15, f"order {n} mismatch"
print("bit-parity OK across torch/jax")
Parity is a float64 guarantee. In float32, both backends round to 32-bit but intermediate orderings can differ at the last bit. Always check parity in float64.
What the release suite checks
Each release runs a dedicated cross-backend suite asserting ULP-equality on
every (activation, order) pair. The headline: 73/73 and 251/251 cross-backend
tests pass per release.
If you see a mismatch
- Confirm dtype. Are both sides float64? (See the tip above.)
- Confirm the same activation name and that neither side registered a custom override.
- Confirm order support. A
NotImplementedErroron one backend means the order is not implemented there — that is a support gap, not a parity bug. - File it. A genuine float64 mismatch is a bug; report it with a minimal reproduction.
Why this enables certified numerics
Backend-portable certified numerics is only possible because the bits agree: a certificate produced from the JAX path is meaningful for the PyTorch path, because both descend from the same coefficients. See the Certified register.