eyalroz / printf

Tiny, fast(ish), self-contained, fully loaded printf, sprinf etc. implementation; particularly useful in embedded systems.
MIT License
402 stars 50 forks source link

float autotest failures #178

Closed aboseley closed 4 months ago

aboseley commented 4 months ago

./test/autotest -f -p17 1>/dev/null

OS: Fedora Linux 40 (Workstation Edition) x86_64

fmt = "%+.17f" value = 489.392181396484375000
libc:     "+489.39218139648437500"
our lib:  "+489.39218139648437504"

fmt = "%+.17f" value = -369.679229736328125000
libc:     "-369.67922973632812500"
our lib:  "-369.67922973632812496"

fmt = "%+.17f" value = 793.817443847656250000
libc:     "+793.81744384765625000"
our lib:  "+793.81744384765624992"

fmt = "%+.17f" value = -581.847717285156250000
libc:     "-581.84771728515625000"
our lib:  "-581.84771728515624992"

fmt = "% .17f" value = -320.369110107421875000
libc:     "-320.36911010742187500"
our lib:  "-320.36911010742187504"

fmt = "% .17f" value = 771.880187988281250000
libc:     " 771.88018798828125000"
our lib:  " 771.88018798828124992"

fmt = "%.17f" value = 28.715805053710937500
libc:     "28.71580505371093750"
our lib:  "28.71580505371093752"
eyalroz commented 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.

aboseley commented 4 months ago

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

aboseley commented 4 months ago

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"
eyalroz commented 1 month ago

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.