Fix issues with floating point precision and rounding #163
+266
−50
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Dec 18, 2025
Member
|
Jenkins, ok to test. |
This commit started off because I wanted to remove MPFR as a dependency. After an initially-incorrect attempt at doing so, I discovered two more problems. First, the test suite didn't have any tests verifying that MPFR actually fixed the problem it was introduced to fix (correctly rounding results like 0.1*1000 to 100 instead of 99). Second, MPFR gets 0.1*1000, but still makes rounding mistakes in other cases--I found this out by fuzzing after my initial incorrect patch. So now I've replaced MPFR with exact rational math in libgmp, and added regression tests for the rounding errors in string parsing. To do this, I had to do the parsing manually; I followed the same regex approach that the existing function uses. Signed-off-by: Jon Oster <[email protected]>
tkfu
force-pushed
the
feat/use-rational-arithmetic
branch
from
f84dab9 to
4797c5d
Compare
Member
|
Thank you! I need to spend some more time doing a proper review, but in general this looks great. I ran the blivet test suite as well and it found two issues:
Btw. you can ignore the one failed test run, that was Fedora 43 machine and it failed because of an infrastructure issue. |
Switching to internal parsing logic caused two changes to existing behaviour. "1. KiB" was previously accepted, and parsed the same as "1.0 KiB". And "e+0" was previously not accepted, raising an error; with the new parsing it's parsed as 0. This was found by an external test suite, so we're adding these cases to the internal suite as well. Signed-off-by: Jon Oster <[email protected]>
Contributor
Author
|
I added those cases to the unit test suite, now working on the fixes. |
Allows parsing of strings with a decimal but no decimal part, e.g. "1. KB". Fails to parse if there is no number present by adding a validation check to ensure that either the integer part or the fractional part has len > 0. Signed-off-by: Jon Oster <[email protected]>
Contributor
Author
|
Should be all set. |
vojtechtrefny
approved these changes
Jan 15, 2026
Member
vojtechtrefny
left a comment
vojtechtrefny
left a comment
There was a problem hiding this comment.
Thank you for the fixes. I finally went through this more thoroughly and it looks great, thank you again.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit started off because I wanted to remove MPFR as a dependency. After an initially-incorrect attempt at doing so in #161, and a nice review by @PlasmaPower, I discovered two more problems. First, the test suite didn't have any tests verifying that MPFR actually fixed the problem it was introduced to fix (correctly rounding results like 0.1*1000 to 100 instead of 99). Second, MPFR gets 0.1*1000 right, but still makes rounding mistakes in other cases--I found this out by doing some fuzzing after my initial incorrect patch.
So now I've replaced MPFR with exact rational math in libgmp, and added regression tests for the rounding errors in string parsing. To do this, I had to do the parsing manually; I followed the same regex approach that the existing bs_size_new_from_str function uses.