Project

General

Profile

Actions

Feature #17339

open

Semantic grouping with BigDecimal#to_s

Added by chumaltd (Takahiro Chuma) 9 months ago. Updated 8 months ago.

Status:
Assigned
Priority:
Normal
Target version:
-
[ruby-core:100999]

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

Summary

We want to have a natural format.

Actions #1

Updated by sawa (Tsuyoshi Sawada) 9 months ago

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

Updated by nobu (Nobuyoshi Nakada) 9 months 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) 9 months 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) 9 months 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.

Actions #5

Updated by chumaltd (Takahiro Chuma) 9 months ago

  • Description updated (diff)

Updated by chumaltd (Takahiro Chuma) 8 months 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) 8 months ago

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

Also available in: Atom PDF