Repository navigation
document approach to accuracy #134
Description
Following up on the recent discussion at #45, we should perhaps consider documenting the package's approach to accuracy.
I would say roughly this:
- We aim for accurate implementations of at least
Float64inputs. "Accurate" is determined as a practical trade-off. - Most methods have
::Float32and::Float16implementations, with similar aims. - All methods have a generic fallback, which may not be as accurate but should not produce wildly incorrect results.
- Docstrings should document more specific claims for each method.
- If more accuracy is needed, please open an issue.
Activity
tpapp commentedon Nov 9, 2026
Also, just my personal comment: I usually work with logs because they improve accuracy of my calculations per se. They are very costly (it is not uncommon for LogExpFunctions to eat up 50% of CPU time in an economic model), but worth it because they handle differing magnitudes so well.
However, I don't need log calculations themselves to be accurate to the last ulp. For my purposes accuracy comes from just using logs, not the logs being super-accurate. At some point diminishing returns kick in.
andreasnoack commentedon Nov 9, 2026
I've summarized the situation in #135. I don't think it is a matter of losing a bit of precision. The fallbacks can lose almost all precision, and in a larger codebase, it can be quite hard to identify where such loss of precision happens. As mentioned in #45, my opinion is that functions like the ones in this repo should only be defined when they provide reasonable precision.