Closed aboseley closed 4 months ago
This is not an issue, in the sense that identity with libc at 17 decimal digits is not guaranteed.
But - accuracy improvements, without significant size increases, will be considered as a PR.
It would be nice to have the autotest return an clean set of results at these extremes, 17 digits is the default precision applied if none is specified
Hey @eyalroz ,
I'm not sure if this is related but could you take a look at this, I added another test mode to try all the conversions in a range.
https://github.com/aboseley/printf/tree/adam/sequential_test
When I run with
test/autotest -s-42 -d1 -p8
I appear to get rounding failures at the 8'th place
fmt = "%0.8f" value = -41.999999185000000068
libc: "-41.99999919"
our lib: "-41.99999918"
fmt = "%0.8f" value = -41.999997725000000059
libc: "-41.99999773"
our lib: "-41.99999772"
I don't guarantee last-ulp identity with glibc... to do that, I would more or less need to copy their code. And while there is a discrepancy here, it is not a failure; it is just that the accuracy of the decimal base conversion is imperfect, in favor of simplicity.
If you have a concrete PR which improves accuracy, I would consider it.
./test/autotest -f -p17 1>/dev/null
OS: Fedora Linux 40 (Workstation Edition) x86_64