Feature #17339
openSemantic grouping with BigDecimal#to_s
Description
Abstract¶
Thousands, millions, ... should be expressible with BigDecimal#to_s
.
Background¶
BigDecimal('1234567').to_s('3F')
returns "123 456 7.0".
Proposal¶
- Have an option with which
BigDecimal('1234567').to_s('3F')
returns "1 234 567.0". - With decimal,
BigDecimal('1234567.8901234').to_s('3F')
should return "1 234 567.890 123 4". - Default behavior should be the above in long term.
- And/Or, it would be nice to have a pretty method name. I think #to_s('3F') has universal use cases like money calculation.
Discussion¶
- International System of Units aka SI defines 3-digit-grouping on long numeric sequence.
https://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=22&RES=10 - Original discussion in 1948 shows some example of 3-digit-grouping.
https://www1.bipm.org/utils/common/pdf/CGPM/CGPM9.pdf#page=117
Summary¶
We want to have a natural format.
Updated by sawa (Tsuyoshi Sawada) almost 4 years ago
- Subject changed from Semantic grouping on BigDecimal#to_s to Semantic grouping with BigDecimal#to_s
- Description updated (diff)
Updated by nobu (Nobuyoshi Nakada) almost 4 years ago
Its document states:
If s contains a number, a space is inserted after each group of that many fractional digits.
If this is correct, grouping the integer part seems unintentional.
Updated by nobu (Nobuyoshi Nakada) almost 4 years ago
Shouldn't BigDecimal('1234567').to_s('3F')
return "1 234 567.0"
(without spaces at the beginning and just before the decimal dot), but not " 1 234 567 .0"
, right?
We should consider this statement says nothing about the integer part, I guess now.
Updated by chumaltd (Takahiro Chuma) almost 4 years ago
nobu (Nobuyoshi Nakada) wrote in #note-3:
Shouldn't
BigDecimal('1234567').to_s('3F')
return"1 234 567.0"
(without spaces at the beginning and just before the decimal dot), but not" 1 234 567 .0"
, right?We should consider this statement says nothing about the integer part, I guess now.
Thank you for discussion.
Yes, I mean "1 234 567.0" without heading space. It's just a mistake.
to_s
may not be changed for consistency. Some new method will be ok.
I just couldn't remind "123 456 7.890 12" use case.
Updated by chumaltd (Takahiro Chuma) almost 4 years ago
- Description updated (diff)
Updated by nobu (Nobuyoshi Nakada) almost 4 years ago
https://github.com/ruby/ruby/compare/master...nobu:bug/17339-BigDecimal%23to_s-grouping?expand=1
Improves (especially for the doc) are welcome.
Updated by chumaltd (Takahiro Chuma) almost 4 years ago
I read doc again, and understand the situation.
If we have a chance to change API, another formatting option like #to_s('G')
can be good that works as '3F'.
Then we'll have beautiful 'E', 'F', 'G' options.
As I referred, SI confirmed 3 digit grouping policy twice(1948 and 2003). Other than 3 is not preferred way.
I think financial or business common practices follow 3 digit rule, too.
So, grouping option should have its default, and formatting with digit like '5F' will be more private.
Updated by mrkn (Kenta Murata) almost 4 years ago
- Status changed from Open to Assigned
- Assignee set to mrkn (Kenta Murata)
Updated by mrkn (Kenta Murata) almost 3 years ago
- Related to Feature #18410: Proposal to make inspect include underscores on numerics added
Updated by mrkn (Kenta Murata) almost 3 years ago
I will follow the consequence of #18410.
Updated by cryptogopher (crypto gopher) over 1 year ago
I've sent pull request with solution as specified by author of issue: https://github.com/ruby/bigdecimal/pull/264