Project

General

Profile

Actions

Feature #17339

open

Semantic grouping with BigDecimal#to_s

Added by chumaltd (Takahiro Chuma) 11 months ago. Updated 10 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) 11 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) 11 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) 11 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) 11 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) 11 months ago

  • Description updated (diff)

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

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

Also available in: Atom PDF