BUG: read_csv c engine loses float precision with thousands separator (GH#44145)#66010
Draft
jbrockmendel wants to merge 1 commit into
Draft
BUG: read_csv c engine loses float precision with thousands separator (GH#44145)#66010jbrockmendel wants to merge 1 commit into
jbrockmendel wants to merge 1 commit into
Conversation
… (GH#44145) precise_xstrtod only routed to the correctly-rounded fast_float parser when no thousands separator was set, so read_csv(thousands=...) fell back to the bespoke parser and could be off by up to a couple of ULP on long-mantissa floats. Strip the integer-part separators into a scratch buffer and hand the token to fast_float, keeping the strict acceptance of the fallback for malformed input. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
closes #44145
to_numericalready parses high-precision float strings to the correctly-roundedfloat64(matching the Pythonfloatbuiltin) via fast_float, butread_csvwith athousandsseparator did not.precise_xstrtodonly dispatched to fast_float when no thousands separator was set, soread_csv(thousands=...)fell back to the bespoke parser, which could be off by up to a couple of ULP on long-mantissa floats (~12% of random long-mantissa values in a fuzz).The fix strips the integer-part separators into a scratch buffer and hands the token to fast_float. A thousands separator is only valid in the integer part where it follows a digit, so the strip is position-aware (separators elsewhere are kept, causing fast_float to stop there) — this preserves the strict acceptance of the old fallback for malformed input like
1,_2,1_000,000_000, and1,e1_2. The consumed length is mapped back to the original string soendptr/trailing-character handling stays correct. The no-thousands path is unchanged.