Fix format_number producing bogus output for large integers#83
Open
gaoflow wants to merge 1 commit into
Open
Conversation
When format_number() receives an integer >= 10**16, str(float(number))
produces scientific notation (e.g. '1e+16'). The subsequent .partition('.')
call then returns ('1e+16', '', '') since there is no decimal point, and
the comma-insertion loop operates on the '1e+...' text as if it were
plain digits, yielding garbage output like '1e,+16'.
Fix by short-circuiting the float conversion for plain int types (using
type(x) is int) and using str(number) directly instead. This preserves
the exact decimal representation and lets the existing comma-insertion
and sign logic work correctly.
Fixes a wrong-results bug where format_number(10**16) returned '1e,+16'
instead of '10,000,000,000,000,000'.
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
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.
format_number() returns corrupted output like
'1e,+16'for any integer>= 10**16. The root cause:str(float(n))produces scientific notationfor those values (e.g.
'1e+16'), then.partition('.')sees no decimalpoint and the comma-insertion loop consumes the scientific-notation text
as if it were plain digits.
Before this fix:
After this fix:
The same bug affects any integer in the
[10**16, 10**30)range wherestr(float(n))switches to scientific notation. Beyond that range theinteger literal itself would lose precision in the float conversion.
The fix avoids the unnecessary
float()round-trip for plainintvalues, preserving the exact decimal string and letting the existing
comma-insertion and sign logic work correctly.
This PR was written with assistance from an AI tool (Claude Code),
under my direction and review.
Closes #NEW (issue not yet filed)