Feature #17339: Semantic grouping with BigDecimal#to_s

• Status: Assigned
• Assignee: mrkn (Kenta Murata)
• Target version: -

[chumaltd (Takahiro Chuma)]

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.

[sawa (Tsuyoshi Sawada)]

• Subject changed from Semantic grouping on BigDecimal#to_s to Semantic grouping with BigDecimal#to_s
• Description updated (diff)

[nobu (Nobuyoshi Nakada)]

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.

[nobu (Nobuyoshi Nakada)]

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.

[chumaltd (Takahiro Chuma)]

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.

[chumaltd (Takahiro Chuma)]

• Description updated (diff)

[nobu (Nobuyoshi Nakada)]

https://github.com/ruby/ruby/compare/master...nobu:bug/17339-BigDecimal%23to_s-grouping?expand=1

Improves (especially for the doc) are welcome.

[chumaltd (Takahiro Chuma)]

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.

[mrkn (Kenta Murata)]

• Status changed from Open to Assigned
• Assignee set to mrkn (Kenta Murata)

[mrkn (Kenta Murata)]

• Related to Feature #18410: Proposal to make inspect include underscores on numerics added

[mrkn (Kenta Murata)]

I will follow the consequence of #18410.

[cryptogopher (crypto gopher)]

I've sent pull request with solution as specified by author of issue: https://github.com/ruby/bigdecimal/pull/264