Repository navigation
Read 12,5 as 12.5 when normalising amounts - #5
Merged
Merged
Conversation
_norm_amount treated a lone comma as a thousands separator unless exactly two digits followed it, so "12,5" became 125.0. A comma is now a thousands separator only when every group after it has exactly three digits (1,204 or 12,000,000); otherwise it is a decimal comma. verify/score.c had the same rule and gets the same fix, checked on a copy of the reports with seven extra comma cases (the old C disagrees on 4 field verdicts, the new one on none). Parametrized test added; two cases fail on the old code. Rescoring every stored prediction with the new rule changes no verdict, so no published numbers change. Co-authored-by: aghasalim <75713741+aghasalim@users.noreply.github.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.
_norm_amount treated a lone comma as a thousands separator unless exactly two digits followed it, so "12,5" became 125.0. A comma is now a thousands separator only when every group after it has exactly three digits (1,204 or 12,000,000); otherwise it is a decimal comma. verify/score.c had the same rule and gets the same fix, checked on a copy of the reports with seven extra comma cases (the old C disagrees on 4 field verdicts, the new one on none). Parametrized test added; two cases fail on the old code. Rescoring every stored prediction with the new rule changes no verdict, so no published numbers change.
Co-authored-by: aghasalim 75713741+aghasalim@users.noreply.github.com