Repository navigation
Fix precision loss for fixed-point values with non-zero scale - #1835
Merged
sfc-gh-pfus merged 2 commits intoAug 18, 2026
Merged
Conversation
Collaborator
|
Hi @tanner-lai ! Thanks for your contribution, it seems correct. Can you add a changelog.md entry? |
Both non-higher-precision conversion paths for fixed-point values routed the exact unscaled integer through a binary float before formatting it, silently rounding values carrying more significant digits than the float's mantissa could hold. arrowDecimal128ToValue divided using a 64-bit big.Float, so NUMBER(20,10) holding 1234567890.1234567890 returned 1234567890.1234567889; arrowIntToValue divided as float64, so NUMBER(18,4) holding 12345678901234.5678 returned 12345678901234.5684. Both now format from the unscaled integer via decimal128.ToString, as the scale == 0 branch already did. The higherPrecision paths still return *big.Float and are left unchanged, since that return type is approximate by contract.
tanner-lai
force-pushed
the
fix-decimal-scale-precision
branch
from
August 7, 2026 14:11
0e7dd4e to
9dec3ca
Compare
|
All contributors have signed the CLA ✍️ ✅ |
Contributor
Author
|
I have read the CLA Document and I hereby sign the CLA |
Contributor
Author
Just added an entry, thanks! |
Contributor
Author
|
@sfc-gh-pfus Is there anything left to address? Do you guys have a practice to older versions/do I need to make those PRs as well? |
Collaborator
|
@tanner-lai sorry, I was on holiday. I'll get to your PR this week! |
sfc-gh-pfus
approved these changes
Aug 18, 2026
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Description
Both non-higher-precision conversion paths for fixed-point values routed the exact unscaled integer through a binary float before formatting it, silently rounding values carrying more significant digits than the float's mantissa could hold. arrowDecimal128ToValue divided using a 64-bit big.Float, so NUMBER(20,10) holding 1234567890.1234567890 returned 1234567890.1234567889; arrowIntToValue divided as float64, so NUMBER(18,4) holding 12345678901234.5678 returned 12345678901234.5684. Both now format from the unscaled integer via decimal128.ToString, as the scale == 0 branch already did. The higherPrecision paths still return *big.Float and are left unchanged, since that return type is approximate by contract.
Checklist