Curious how people here think about numerical accu...

# mathematics

[Michal Harakal]

Curious how people here think about numerical accuracy across heterogeneous compute.
If the same tensor operation runs with different dtypes and eventually across CPU, GPU, NPU and what should “numerically correct” actually mean?
Exact equality is unrealistic, but a single epsilon also feels too naive.
How would you define a good accuracy contract for a tensor framework?

[Michal Harakal]

For context, I’m working on SKaiNET, a Kotlin Multiplatform ML/AI framework, meaning we’re implementing the lower-level machinery ourselves: tensor operations, dtypes, automatic differentiation/gradients and execution across different backends, rather than just building models on top of an existing framework.
For validation, we currently use Pytorch as the reference implementation: tensor results and gradients are calculated there and compared against the Kotlin implementation.
That raised a surprisingly difficult question: how do we decide scientifically whether two numerical results are “the same enough”?
A tiny local difference may be irrelevant, or it may propagate through a computation graph and become significant in the gradients.
This problem is what led me to create NumCrux — an attempt to explore numerical accuracy more systematically than just “pass/fail within epsilon”:
github.com/numcrux
I’d really value feedback from people with numerical/scientific computing experience: what would you measure, and what would make an accuracy model convincing to you?
ULPs, relative/absolute error, conditioning, gradient sensitivity, statistical approaches, reproducibility across hardware or something else?

[altavir]

I saw those discussions but I think that they rise mostly because people do not have real experience with data. The problem with precision is that you have two types: precision of computation and uncertainty from data. Precision of computations is easy to estimate and mathematicans/CS usually focus on it. Uncertainty from data is hard (I have a separate lections on this in my course). Especially in ML where you do not have variability in data sources.

The thing is uncertainty in data is almost always much larger than precision of computations. So it does not make any sense to improve precision.

[altavir]

If your computation precision affects you beyond data uncertainty it means one of the following:
• You have unstable computation algorithm (error accumulation). But it happens only if you implement something yourself.
• You have unstable data processing (small changes in data cause large changes in the result). It means that you need to change processing, not improve precission.

[altavir]

As for numerical methods, you need to check stability, not precision: en.wikipedia.org/wiki/Numerical_stability

[altavir]

Though refence data is always good... as long as its stability is ensured.

[Michal Harakal]

Thanks, Alexander, the distinction between computational precision, data uncertainty and numerical stability is useful.
I’m one of the SKaiNET developers, so your first case applies directly to us: we implement the low-level tensor ops, dtypes, autodiff, and backends ourselves.
For NumCrux, I’m trying to understand how to distinguish expected floating-point variation from actual numerical instability when the same computation runs across different dtypes and hardware (CPU/GPU/NPU).
I’d love any concrete suggestions on what is actually worth measuring:
• ULP / relative / absolute error
• conditioning / sensitivity
• error growth through a computation graph
• gradient impact
• statistical distribution of differences
• forward/backward stability
• something else?
Also very interested in good test cases or numerical workloads that expose instability rather than simply measuring small precision differences.

[altavir]

The best way is to introduce a distortion into the initial data and see how it changes the result. The problem is that there is no general way to introduce distortion. It depends on the problem